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About this document 


ATTENTION 
The UCS12 software release does not support Enhanced Operator 
Position System (EOPS) functionality. The UCS software continues to 
support operator assisted calls through other platforms such as 
Enhanced Services Provider (ESP). Refer to Appendix A in the UCS 
DMS-250 Feature Change Reference Guide for additional information 
about EOPS removal. 


This publication describes the Release Link Trunk (RLT) functionality on 
the UCS DMS-250 switch. Although the switches provide RLT 
functionality, the services platforms initiate the RLT process. An Enhanced 
Services Provider (ESP) is an example of a services platform. An ESP is a 
software system that provides specialized switching, billing, and call 
processing features. 


This publication includes data tables, office parameters, and commands that 
support RLT functionality. Although these items may pertain to other 
applications, this document addresses only those aspects that directly affect 
RLT functionality. For information on how the data tables, office 
parameters, and commands support other applications, see the appropriate 
publication listed in the section entitled References in this document. 


Intended audience 
This publication assists telecommunications engineers, technicians, 
switching system developers, operating company personnel, and anyone else 
who requires technical information on RLT functionality. 
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x About this document 


How this document is organized 
The chapters in this publication provide the following information: 


Chapter 1, RLT functionality 
Chapter 1 introduces RLT, defines important terms, describes common call 
scenarios, and details important limitations and restrictions. 


Chapter 2, RLT implementation 
Chapter 2 assists you in filling data tables that RLT functionality requires; 
specifically, it defines office parameters that support RLT functionality. 


Chapter 3, SS7 ISUP RLT messages and protocol 

Chapter 3 provides technical specifications and technical details for the 
Signaling System 7 (SS7) Integrated Digital Services Network (ISDN) User 
Part SUP) messages and parameters that provide RLT functionality. 


Chapter 4, Common RLT call scenarios 
Chapter 4 summarizes the flow of SS7 ISUP messages between UCS 
DMS-250 switches and a services platform that supports RLT capabilities. 


Chapter 5, RLT call scenarios for ESP 

Chapter 5 summarizes the flow of SS7 ISUP messages between a bridging 
UCS DMS-250 switch, a remote UCS DMS-250 switch, and an Enhanced 
Services Provider (ESP). 


Chapter 6, RLT call scenarios for non-operator calls 


Chapter 6 summarizes the flow of SS7 ISUP messages between a bridging 
UCS DMS-250 switch, a remote UCS DMS-250 switch, and an Enhanced 
Services Provider (ESP) for non-operator calls. 


Chapter 7, Billing for RLT calls 
Chapter 7 describes how UCS DMS-250 switches generate billing records 
for RLT calls. 


Chapter 8, Common RLT billing scenarios 
Chapter 8 describes how an ESP can override UCS DMS-250 switches when 
generating billing records for RLT calls. 


How to check the version and issue of this document 


The version and issue of the document are indicated by numbers, for 
example, 01.01. 


The first two digits indicate the version. The version number increases each 
time the document is updated to support a new software release. For 


297-2621-345 Standard 04.02 November 1999 


About this document xi 


example, the first release of a document is 01.01. In the next software release 
cycle, the first release of the same document is 02.01. 


The second two digits indicate the issue. The issue number increases each 
time the document is revised but released again in the same software release 
cycle. For example, the second release of a document in the first software 
release cycle is 01.02. 


This document is written for all UCS DMS-250 Family offices. More than 
one version of this document may exist. To determine whether you have the 
correct version of this document for the software in your office, check the 
release information in the UCS DMS-250 Master Index of Publications. This 
index also describes how documentation for your product is organized. 


References in this document 
This publication includes references to the following documents: 


e UCS DMS-250 Billing Records Application Guide, 297-2621-395 

e UCS DMS-250 Data Schema Reference Manual, 297-2621-851 

e UCS DMS-250 Feature Change Reference Guide, 297-2621-050 

e UCS DMS-250 Master Index of Publications, 297-2621-001 

Other documents that contain information that relates to RLT functionality 
include the following: 


e UCS DMS-250 Integrated Services Digital Network (ISDN) Reference 
Guide, 297-2621-106 


e UCS DMS-250 Office Parameters Reference Manual, 297-2621-855 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


1-1 


RLT functionality 


This chapter describes the Release Link Trunk (RLT) functionality for the 
UCS DMS-250 switch. 


RLT capability for SS7 trunks 
Using elements of a Signaling System 7 (SS7) Integrated Services Digital 
Network (ISDN) User Part (ISUP), an SS7 RLT connects a remote UCS 
DMS-250 switch to a services platform such as an Enhanced Services 
Provider (ESP). An ESP consists of a software system that provides 
specialized switching, billing, and call processing features. 


ATTENTION 
The UCS12 software release does not support Enhanced Operator 
Position System (EOPS) functionality. The UCS software continues to 
support operator assisted calls through other platforms such as 
Enhanced Services Provider (ESP). Refer to Appendix A in the UCS 
DMS-250 Feature Change Reference Guide for additional information 
about EOPS removal. 


Although the UCS DMS-250 switches provide RLT capability, the services 
platform initiates RLT. RLT functionality allows a UCS DMS-250 switch to 
release an ISUP inter-machine trunk (IMT) while the same or another UCS 
DMS-250 switch bridges one call’s originator or terminator to a second 
call’s terminator. After RLT, the ESP is available for other calls. RLT 
functionality increases a UCS DMS-250 switch’s traffic handling capacity 
and saves resources during call routing. Without RLT, the ESP and the 
trunks involved must maintain at least one call connection until a call is 
over. 


SS7 RLT functionality is available between the following entities: 
e two or more UCS DMS-250 switches 
e a UCS DMS-250 switch and an ESP 
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UCS DMS-250 switches with SS7 RLT functionality also generate billing 
records for RLT calls. For information on billing records, refer the UCS 
DMS-250 Billing Records Application Guide. 


Figure 1-1 shows the trunk interworkings for the remote UCS DMS-250 
switch and its connection to the ESP services platform. This figure indicates 
the types of trunk group originations for calls entering the network. These 
trunks and connections use the Universal Carrier Protocol (UCP). 


Figure 1-1 
ISUP trunk interworkings for RLT at an ESP 


Services platform 
IEC 


ONAL FGA —— > 


ONATFGB ————— > 


ONAT FGC ——————————> 


EANT ISUP FGD ——___-»| Remote 
UCS 


EANTIMTFGD —__________s| DmMS-250 O 
IMT ISUP ————————»|_ switch 

IMT PTS —— > 

DAL —————————— > 

PRI —— > 


Note: IMT (ISUP) and IMT (PTS) agencies do not allow reorigination with RLT functionality 


Protocols that support RLT capabilities 


The Universal Carrier Protocol (UCP) provides SS7-based communication 
between the remote UCS DMS-250 switch and the services platform. 


Explanations for important RLT terms 


The following subsections define important RLT terms that this publication 
uses frequently. 


Bridging and the bridging switch 
When a switch bridges a call for RLT functionality, it connects the 
originating or terminating trunk of one call to the terminating trunk of a 
second call. The bridging UCS DMS-250 switch bridges the call and 
maintains the call connection. Any switch with RLT capability, including the 
remote switch, can bridge calls. A switch bridges calls only when it cannot 
remove itself from the call connection by passing the bridge request to 
another switch. To bridge calls, a switch between the bridging and service 
platform switches must have RLT capability. 
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Originating switch, terminating switch, and call legs 


A switch that connects to the calling party is an originating switch. A switch 
that connects to the called party is a terminating switch. A call’s first leg 
connects the originating switch to ESP. A call’s second leg connects the ESP 
to the terminating switch. For an ESP call, the services platform makes a call 
to the terminating switch before it connects a call to the originating switch, 
establishing the second call leg before the first call leg. A call’s point of 
connection, not the order in which the network establishes a call, defines it 
as a first or second leg. 


The switching network passes Facility Accept, Facility Request, and Facility 
Reject messages over the trunk circuit associated with the first leg of a call. 
An ESP, or a third party platform, initiates the second leg of a call. The order 
in which an ESP establishes call legs does not affect RLT functionality. 
Figure 1-2 shows an example of call legs in an RLT scenario. 


Normal and boomerang reorigination 


UCS DMS-250 switches allow normal reorigination, by providing a dial 
tone to the calling party so that another call can be made by entering only a 
new address. The UCS DMS-250 switches also allow boomerang 
reorigination, by using the original dialed number to route the reoriginated 
call instead of prompting for a new address (as is the case in normal 
reorigination). Only ESP services support boomerang reorigination, such as 
returning to the main menu of a voice response system. 


Important call types 
A non-operator call occurs when a UCS DMS-250 switch routes a call 
without a 0+ or 0- address to a services platform. An operator services call 
occurs when a UCS DMS-250 switch routes a call with a 0+ or 0- address to 
an operator. An operator-initiated call occurs when the services platform 
initiates a call to both call parties, creating both the first and second call legs. 


Note: If the office parameter field ALL_RLT_OPR_CALLS is Y, then all 
calls that terminate to an RLT trunk are considered operator calls. 
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Figure 1-2 
Example of call legs 


(1) Customer originates call (first leg) to services platform 


Bridging Remote Services platform 


switch switch 


Services platform 
switch 


Legend 


First leg of call ee 
— 
«-———-— Second leg of call | Bridging 
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Common RLT call scenarios 


The following scenarios are the most common that involve RLT 
functionality. For details about these call scenarios, refer to Chapter 4, 
“Common RLT call scenarios.” 


ESP redirect and transfer scenario 


In this scenario, the ESP transfers the call to its destination and requests 
RLT. After the appropriate switch bridges the call, the RLT capability frees 
the services platform and the remote UCS DMS-250 switch. 


Third-party interaction scenario 


In this scenario, a call requires that the ESP place a three-way call, such as a 
third-party call, collect call, or person-to-person call. When the parties are in 
conference, the ESP requests RLT. After the appropriate switch bridges the 
call, the RLT capability frees ESP and the remote UCS DMS-250 switch, 
dropping the ESP out of the call. 


ESP-initiated call back scenario 


In this scenario, the ESP disconnects a call without connecting it to a 
terminator. A services platform disconnects a call if the terminator is not 
available. Later, the ESP initiates a call to the first call’s terminator, then 
initiates a second call to the first call’s originator, and requests RLT. After 
the appropriate switch bridges the call, the RLT capability frees the services 
platform and the remote UCS DMS-250 switch. With this scenario, the 
second leg of the RLT call is set up before the first call leg. 


Billing descriptions for common RLT call scenarios 
Using the RLT functionality, UCS DMS-250 switches can generate an 
operator service record (OSR), a call detail record (CDR), or both for RLT 
calls. The bridging switch produces an OSR and CDR pair for calls to the 
services platform. Refer to Chapter 7, “Billing for RLT calls,” for more 
details. For detailed information on billing records and OSR and CDR pair 
formats, refer to the UCS DMS-250 Billing Records Application Guide. 


A UCS DMS-250 bridging switch generates an OSR and CDR pair after the 
call is completed. A Facility Request (FAR) message that requests a bridge 
might not contain a Calling Party Number parameter or a Called Party 
Number parameter. In either case, the bridging switch pulls billing 
information from the call’s CDR and places the information in an OSR. 


If bridging is unsuccessful at all switches involved in the call, only the 
services platform generates the OSR and CDR. These records contain 
current information for operator services calls. 
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To generate an OSR, the configuration of any UCS DMS-250 bridging 
switch must include the operator recording units and UCS DMS-250 
recording units. When a switch that bridges an RLT call lacks operator 
recording units, it generates an appropriate log report. 


Office parameters for RLT billing 


The UCS DMS-250 switches need the following office parameters to 
generate an OSR, a CDR, or both: 


Dependencies 


The NO_OF_EOPS_REC_UNITS office parameter in table OFCENG 
allocates the number of operator recording units that a switch has 
available. 


The CDR_FOR_ISUP office parameter in table OFCVAR controls 
billing generation. If this parameter is Y, the bridging switch can 
generate a CDR and OSR pair. If this parameter is N, the bridging switch 
cannot generate a CDR and OSR pair. This office parameter is active 
only when a call originates on an ISUP IMT, and only when the 
CDR_FOR_IMT office parameter is inactive. 


The CDR_UNAVAIL_BLOCK office parameter in table OFC VAR 
allows a switch to block a call that does not provide extension blocks. 

If this parameter is Y, the switch applies NO_LSERVICE_CRKT (NOSC) 
treatments to block calls with no extension blocks. If this parameter is N, 
the switch does not block calls that do not have extension blocks. This 
parameter does not block call reoriginations. 


The OSR_FOR_ISUP office parameter in table OFCVAR also controls 
billing generation. If this parameter is Y, the bridging switch can 
generate a CDR and OSR pair. If this parameter is N, the bridging switch 
cannot generate a CDR and OSR pair. This office parameter is active 
only when a call originates on an ISUP IMT, and only when the 
CDR_FOR_IMT office parameter is inactive. 


The RLT_FIRST_ANM_BILLING office parameter in table OFCVAR 
controls whether or not billing for RLT calls begins with the first ANM 
message received or the last ANM message received. If this parameter is 
Y, billing begins from the receipt of the first ANM message. If this 
parameter is N, billing begins from the receipt of the last ANM message. 


To support RLT functionality, a UCS DMS-250 switch does not require any 
special hardware. However, all switches that support RLT functionality must 
have the software shown in Table 1-1. 
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Table 1-1 

RLT Software Requirements 
UCS06 SOC order code UCS06 SOC option name 
URLT0001 URLT enhanced network server 
URLT0002 URLT enhanced reorigination 
URLT0003 URLT nonzero RLT 


RLT support capabilities 


UCS DMS-250 switches with RLT functionality support reorigination on the 
following agencies: 


e dedicated access line (DAL) 


e FGA 

e FGB 

e FGC 

e per-trunk signaling (PTS) FGD 
e ISUP FGD 


Note: UCS DMS-250 switches support RLT functionality only on ISUP 
IMTs with the UCP for which table TRKGRP contains an active RLT 
option. 


UCS DMS-250 switches with RLT functionality support the following call 
classifications: 
e Calls not designated as operator-assisted (OA) can reoriginate to the 
services platform. 
e RLT functionality allows reorigination only for the following 
station-to-station or person-to-person, non-collect billing types: 
— calling card 
— credit card 
— automatic numbering identification (ANI) 


— authorization code 
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Limitations and restrictions 
Trunk and protocol compatibility 


When a call originates on an ISUP IMT with RLT capability and terminates 
at either an ISUP FGD trunk or an ISUP IMT that lacks RLT capability, the 
UCS DMS-250 switches do not pass parameters that are specific to RLT. 


Reorigination 
The following describes the reorigination functionality of the RLT: 


e The Initial Address Message (IAM) delivered on a redirected boomerang 
call will contain the same optional parameters as the original IAM 
delivered on the first call, assuming that no datafill changes have been 
made between the first call and the boomerang reoriginated call. 


e The IAM delivered on a third party boomerang is rebuilt at the bridging 
switch with the current information available. Therefore, the IAM may 
be different from the IAM delivered on the first call. 


e RLT does not allow reorigination in the following circumstances: 
— third-party billing verification calls 
— calls involving recall to the services platform 
(this includes calls requesting time and charges) 
— calls from a prison 
— 911 calls 
— coin calls 
— calls in a queue for an operator position 


— calls originating from an ESP 


e The Reorigination Type field in the Operation Information parameter of 
the FAR message is found in previous UCS software releases. In those 
releases, value 11 of Reorigination Type was spare and treated as no 
reorigination allowed. Value 11 means looking at the Reorigination; 
therefore, reorigination may not be blocked as in the previous releases 
and it is assumed that the data in the reorigination fields are correct. 


— If an ESP sends a FAR message with value 11 in Reorigination Type, 
the receiving switch may allocate reorigination resources based on 
the Reorigination Fields instead of datafill provisioned in the switch. 


— If these values are sent to UCS DMS-250 switches with previous 
software releases with the FAR messages, it causes blocking on 
reorigination. 


e The REORIG_FOR_OPERATOR_SERVICES office parameter in table 
OFCVAR is not changed in this release and continues to enable or 
disable operator services reorigination on the Originating switch. 
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Standard non-operator RLT calls are not effected by the existing 
REORIG_FOR_OPERATOR_SERVICES office parameter if the 
existing ALL_RLT_OPR_CALLS office parameter is N. 


For non-AXXESS operator calls, the ability to enable reorigination is 
limited to AUTO/MANUAL capability, and boomerang reorigination 
is not supported for direct non-AXXESS operator calls. 


The Bridge Reorig Control field in the Operator Information of a FAR is 
always set to N by the services platform. 


The reorigination fields in the Bridging, Redirecting or Reorigination 
FAR messages override the value in the RECALLDT field of table 
TRKGRP. 


For ESP-initiated callback scenarios, if RLT trunks are involved and the 
Originating switch is not the Bridging switch, the functionality provided 
by this release is supported, as shown in Fig 1-3. 


Figure 1-3 
Message flow for ESP-initiated call back 


IMT trunks are IMT trunks are 
marked as Inter marked as Intra 


Services platform 


Bridging Tandem 
Originating switch switch 


ma 


Terminating 


Using RLT on inter-network IMT 


Using RLT functionality on inter-network IMTs changes some of the 
interactions between interexchange carriers (IECs). 


When using RLT between IECs, UCS DMS-250 switches can allow 
reorigination based on the billing information collected and validated 
at the services platform. 


For example, the services platform sends this billing information to the 
bridging switch over an inter-network IMT as shown in Figure 1-4. This 
switch does not validate the billing information, but can still allow 
reorigination, relying on the correctness of the billing information from 
the services platform. The bridging switch uses this billing information 
to populate its CDR and OSR. 
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e Inter-network IMTs can provide Universal Access (UA) services as 
shown in Figure 1-4. If an inter-network IMT is connected to the remote 
switch and the call is a UA call, then if the call terminates to a services 
platform, the services platform could bridge the call back to the remote 
switch and lose the billing information related to the UA call. The 
bridged call would continue with billing information sent from the ESP, 
not the UA billing information collected on the remote switch. 


e When using RLT between IEC networks, the functionality can result in a 
switch from one IEC network being able to indicate which operator 
queue to route a call to in another IEC network. This could result in 
cases where the datafill on a remote IEC switch in the bridging switch 
network does not match the operator queue configuration on a services 
platform switch in the remote switch network as shown in Figure 1-5. 

Figure 1-4 

Message flow for RLT between IECs 


IMT trunks are IMT trunks are 
marked as Inter marked as Intra 


Bridging Tandem Services platform 


Originating switch switch 


Terminating | 


/—-——— t&ca————4 ! H- IEC B——————— 4 


Special RLT conditions 
The following conditions affect RLT reorigination functionality: 


e RLT does not allow reorigination for operator service calls until the 
services platform extends the call and releases it from the services 
platform. 


e RLT functionality prevents the switches of operator calls from 
translating and routing the reoriginated call. This prevention is based 
upon the original dialed number in the event that the switches have not 
generated a CDR for the current call. The switches apply a 
NO_SERVICE_CRKT (NOSC) treatment for the call, regardless of the 
datafill in the CDR_UNAVAIL_BLOCK office parameter in table 
OFCENG. 


e OSRs for RLT calls are generated by bridging switches, including calls 
that are not operator-assisted. 
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e ANM defines the field REORIGINATION TYPE in the Operator 
Information parameter. The Address Complete Message (ACM), facility 
accept message, and Facility Request (FAR) message do not define this 
field. 


e IAM does not affect the UCS DMS-250 switch based upon the field 
REORIGINATED CALL in the Transit Network Selector (TNS). The 
switch transfers the value of REORIGINATION CALL from the 
received IAM to the dispatched IAM when both the originator and 
terminator are SS7 trunks. 


Note: Only ESPs with proper programming use the reoriginated call 
field in the TNS. 


e If the services platform allows boomerang reorigination and the 
PARMBLK field in table TRKGRP is set to Y on any of the SS7 RLT 
IMTs that the call is routed over, the services platform blocks the 
Generic Digits and TNS parameters in the outgoing IAM message and 
does not send a CALLID to the ESP. 


e RLT does not require switches to segregate 1+ and operator service 
traffic onto different trunk groups. 


e Typically, an RLT call involves only the two trunks between the services 
platform and the remote switches while a services platform interacts with 
the called party. If bridging fails, however, both trunks maintain call 
connections until the call is over. 


e For ESP-initiated callback calls, a switch must answer the first call leg 
before it accepts a FAR message that requests bridging. 


e RLT does not support the use of inward completion codes for directory 
assistance. 


e When calls terminate to ISUP IMTs with RLT capability, the switches in 
the network disable call reorigination. They can detect reoriginations 
only if the originating switch is the bridging switch, only after bridging, 
and only after it receives an ANM that indicates the type of 
reorigination. If any other switch performs bridging (or if the switches 
do not bridge the call at all), the network cannot reoriginate the call. 


Note: This restriction only applies if the office parameter field 
ALL_RLT_OPR_CALLS is Y. 
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RLT implementation 


Because UCS DMS-250 data tables are interactive, they must be datafilled 
in a specific order. This chapter presents the data tables and office 
parameters required for Release Link Trunk (RLT) functionality. 


Data tables and datafill for RLT functionality 
The following tables contain datafill for the RLT functionality: 


e TRKGRP (trunk group) 
e TRKSGRP (trunk subgroup) 


TRKGRP (IMT trunk group type) 
The following fields in table TRKGRP relate specifically to RLT: 


e ISUPIDX 
e CUSTOMER 
e OPTIONS 


Functional description 

Inter-machine trunk (IMT) groups connect the UCS DMS-250 switches to 
other interexchange carrier (IEC) switches in the network. The UCS 
DMS-250 system supports originating, terminating, and two-way access 
over IMTs. Subscribers can originate IMT calls on the UCS DMS-250 
switch and allow compatibility between the customer network and ETN 
switches for private network configurations. 


Datafill sequence and implications 
Operating company personnel must datafill the CLLI and CLLICDR tables 
before table TRKGRP. 


Table 2-1 lists the datafill that RLT functionality requires in table TRKGRP. 
For additional datafill information, see the UCS DMS-250 Data Schema 
Reference Manual. 
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Table 2-1 
RLT-related datafill for table TRKGRP (IMT trunk group type) 
Subfield or 
Field refinement Entry Explanation and action 
ISUPIDX UCS2EAEO, ISUPIDX. This field specifies the interworking 
NILIDX, between the different network domains. This 
UCS2MCI, field’s valid entries are: 
hae or UCS2EAEO. ISUP between a UCS 
DMS-250 switch and an Equal Access End 
Office (EAEO) of an LEC. 

e NILIDX. ISUP calls cannot go through 
when datafill includes NILIDX. Trunks that 
are not ISUP IMTs use this field. 

e UCS2MCI. ISUP between a UCS and an 
MCI DMS-250 switch. 

e UCS2USP. ISUP between a UCS 
DMS-250 switch and a USSPRINT 
DMS-250 switch. 

e UCS2UCS. ISUP between two UCS 
DMS-250 switches. 

CUSTOMER UCSUST, CUSTOMER. Depending on which customer 
UCS type is selected, the technician is prompted 


with the appropriate fields for that customer. 
This field indicates the operating company’s 
dialing plan. UCSUST is required for RLT. 


OPTIONS OPTIONS. This field has several optional 
subfields. The dollar sign ($) indicates the end 
of the options. 


RLT RELEASE LINK TRUNK. Enter RLT to indicate 
which trunk supports the release trunk feature; 
otherwise, omit. 


VERSION V1 PARAMETER BLOCK is a Y or N field within 
PARMBLK the RLT option and is not a separate option. 


LNPRLT LOCAL NUMBER PORTABILITY is an option 
added to inter and intra IMTs. 


Datafill example 
Figure 2-1 illustrates a sample datafill for the table TRKGRP (IMT trunk 
group type). 
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Figure 2-1 
MAP display example for table TRKGRP (IMT trunk group type) 
GRPKEY 
GRPTYP TRAFSNO 
PADGRP NCCLS GRP INFO 
IMT761C7P00 
IMT 40 
NPDGP NCIM UCSUST 0 
2W IMT MIDL 
16 7 16 16 
ucs2ucS NIL CN NONE 4 ALWAYS I3PA 111 0 INTRA N 
VOICE_DATA 
( OHQ ) ( OHQTERM ) (ISDNXFER ) ( ID24_ON ) ( RIT V 1N )$ 
XL J 


TRKSGRP 


Table TRKSGRP lists the supplementary information for each subgroup 
assigned to one of the trunk groups listed in table TRKGRP. The field that 
relates specifically to RLT is the UCP PROTOCOL field, as shown in 
Table 2-2. For additional datafill information, see the UCS DMS-250 Data 
Schema Reference Manual. 


Table 2-2 
RLT-related datafill for table TRKSGRP 
Subfield or 
Field refinement Entry Explanation and action 
PROTOCOL UCP PROTOCOL. Enter UCP as the signaling 


protocol type to provide connectivity. Other 
protocols do not support RLT functionality. 
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Figure 2-2 


Datafill example 
Figure 2-2 illustrates a sample datafill for the table TRKSGRP. 


MAP display example for table TRKSGRP 


y 
SGRPKEY CARDCODE 


SGRPVAR SGRPVAR 


IMT761C71P00 0 DS1SIG 
C7UP 
2W N N UNEQ ACTIVEA UCP THRH 100 DMSNODE $ NIL CIC 


N 


Office parameters 


The office parameters described in the following paragraphs must contain 
datafill for RLT. 


ALL_RLT_OPR_CALLS 


Parameter name 
All Release Link Trunk (RLT) Operator Calls 


Functional description 

The ALL_RLT_OPR_CALLS office parameter in table OFCVAR controls 
whether or not the UCS DMS-250 switches treat non-operator calls made 
over RLT trunks as operator services calls. 


Provisioning rules 
Not applicable 


Range information 

The range of values is Y or N. When the value is Y, the switches treat 
non-operator calls made over RLT trunks as operator service calls. If the 
value is N, the switches treat the calls as normal non-operator calls. 


Minimum Maximum Default 


Y 


Note: 0+/0- calls are still treated as operator services calls. 


Activation 
Immediate 
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Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 


CDR_FOR_ISUP 


Parameter name 
Call Detail Record (CDR) For Integrated Services Digital Network (ISDN) 
User Part (ISUP) 


Functional description 
The CDR_FOR_ISUP office parameter in table OFCVAR controls how a 
switch generates billing for calls from ISUP IMTs. 


This parameter works only when the CDR_FOR_IMT parameter is inactive. 


Provisioning rules 
Not applicable 


Range information 

The range of values is Y or N. When the value is Y, the switch produces 
billing records for all originating ISUP IMT calls. When the value is N, the 
switch does not produce billing records for originating ISUP IMT calls. 


Minimum Maximum Default 
N 
Activation 
Immediate 
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Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 


NO_OF_EOPS_REC_UNITS 


Parameter name 
Number of Enhanced Operator Position System (EOPS) Recording Units 


Functional description 
The NO_OF_EOPS_REC_UNITS office parameter in table OFCENG 
allocates the number of operator recording units that a switch has available. 
Provisioning rules 
Set this parameter to a value that reflects the maximum number of expected 
operator type calls up at any one time. The provisioning rules for the 
operator RU is as follows: 

RLT x (3600 sec + AWT sec) = A 

A x (Avg 250 min + 60 min) + RLT = Operator RU 
where: 
RLT represents the number of Release Link Trunks connected to the switch. 
AWT represents the average wait time of the operator. 


A represents the total calls per hour. 


AVG 250 represents the average call-hold time on the switch. 
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Range information 


Minimum Maximum Default 
0 32767 100 
Activation 


Immediate for increases in parameter values. Cold restart for decreases in 
parameter values 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 


CDR_UNAVAIL_BLOCK 


Parameter name 
Call Detail Record (CDR) Unavailable Block 


Functional description 

The CDR_UNAVAIL_BLOCK office parameter in table OFC VAR allows a 
switch to block a call that does not provide extension blocks. This parameter 
does not block call reoriginations. 


Provisioning rules 
Not applicable 
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Range information 

The range of values is Y or N. If the value is Y, the switch applies 
NO_SERVICE_CRKT (NOSC) treatments to block calls with no extension 
blocks. If the value is N, the switch does not block calls that do not have 
extension blocks. 


Minimum Maximum Default 
Y 
Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
If Y, could lead to blocked calls. 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter. 


OSR_FOR_ISUP 


Parameter name 
Operator Service Record (OSR) For Integrated Services Digital Network 
User Part (ISUP) 


Functional description 
The OSR_FOR_ISUP office parameter in table OFCVAR controls how 
switch generates billing for calls from ISUP IMTs. 


This parameter works only when the CDR_FOR_IMT parameter is inactive. 


Note: To support this parameter, the switch must have the Enhanced 
Tandem Services Software Load (PCL). 
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Provisioning rules 
Not applicable 


Range information 

The range of values is Y or N. When the value is Y, the switch produces 
billing records for all originating ISUP IMT calls. When the value is N, the 
switch does not produce billing records for originating ISUP IMT calls. 


Minimum Maximum Default 
N 
Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 


REORIG_FLEXDIAL_INDEX 


Parameter name 
Reorigination Flexdial index 


Functional description 

This parameter specifies the default index to table FLEXDIAL. For the 
reorigination call using an AXXESS agent, if the index to table FLEXDIAL 
is identified, this default value is used. 


Provisioning rules 
Not applicable 
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Range information 
NIL 


Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Not applicable 


REORIG_MSGCTR_INDEX 


Parameter name 
Reorigination message center index 


Functional description 

This parameter specifies the default index to table MSGCTR. For the 
reorigination call using an AXXESS agent, if the index to table MSGCTR is 
identified, this default value is used. 


Provisioning rules 
Not applicable 


Range information 


The range of values is 0 to 16777215. When the value is 0, the feature is 
deactivated. 


Minimum Maximum Default 


0 
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Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Not applicable 


REORIG_FOR_OPERATOR_SERVICES 


Parameter name 
Reorigination For Operator Services 


Functional description 

The REORIG_FOR_OPERATOR_SERVICES office parameter in table 
OFCVAR controls whether a switch supports operator services 
reoriginations. 


Note 1: To support this parameter, the UCS DMS-250 switch must have the 
Enhanced Tandem Services Base software load (PCL). 


Note 2: When the ALL_RLT_OPR_CALLS office parameter in table 
OFCVAR is set to Y, the switch treats non—operator RLT calls as operator 
services calls and then restricts these calls at bridging using REORIG_FOR 
OPERATOR_SERVICES. 


Provisioning rules 
Not applicable 
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Range information 
The range of values is Y or N. If the value is Y, the switch supports operator 
services reorigination. 


Minimum Maximum Default 
N 
Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 


RLT_EOPS_SWITCH 


Parameter name 
Release Link Trunk (RLT) Enhanced Operator Position System (EOPS) 
Switch 


Note: The UCS12 software release does not support EOPS functionality. 
The UCS software continues to support operator assisted calls through other 
platforms such as Enhanced Services Provider (ESP). 


Functional description 
The RLT_EOPS_SWITCH office parameter identifies the switch as a 
services platform that has RLT capability. 


Provisioning rules 
Not applicable 
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Range information 
The range of values is Y or N. When the value is N, the parameter is inactive 
and the switches cannot use it. 


Minimum Maximum Default 
N 
Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
Not applicable 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 


RLT_FIRST_ANM_BILLING 


Parameter name 
Release Link Trunk (RLT) First Answer Message Billing 


Functional description 

The RLT_FIRST_ANM_BILLING office parameter identifies whether the 
UCS DMS-250 switch begins billing for RLT calls with the first ANM 
message received or the last ANM message received. 


Provisioning rules 
Not applicable 
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Range information 
The range of values is Y or N. When the value is Y, the first ANM will be 
used. If the value is N, the last ANM will be used. 


Minimum Maximum Default 
N 
Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 
If this parameter is Y, make a call to an ESP with multiple redirections and 
verify that billing begins with the first ANM message. 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 


RLT_REDIRECT 


Parameter name 
Release Link Trunk (RLT) Redirect 


Functional description 
The RLT_REDIRECT office parameter identifies whether or not the services 
platform can redirect RLT calls. 


Provisioning rules 
Not applicable 
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Range information 
The range of values is Y or N. When the value is N, the services platform 


cannot redirect RLT calls. When the value is Y, the services platform can 
redirect RLT calls. 


Minimum Maximum Default 
N 
Activation 
Immediate 


Dependencies 
Not applicable 


Consequences 
Not applicable 


Verification 

If this parameter is set to Y, make an operator-assisted call over an RLT 
trunk to a services platform and verify that the call is redirected over that 
same trunk. 


Memory requirements 
This parameter has no memory impact. 


Dump and restore rules 
Copy the existing value of this parameter or consult Nortel Networks 
Customer Engineering. 
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SS7 ISUP RLT messages and protocol 


This chapter describes the Signaling System 7 (SS7) Integrated Digital 
Services Network (ISDN) User Part (SUP) Release Link Trunk (RLT) 
messages that provide connectivity between switching elements in a 
network. It describes each ISUP message along with the parameters that 
these messages use. 


This chapter defines ISUP message formats, ISUP messaging requirements, 
and ISUP message parameters for RLT. 


Note: These parameters are correct for RLT functionality only. 


SS7 ISUP message formats and messaging requirements 


This section provides SS7 ISUP message information, describing the format, 
encoding, and RLT application of each message. Table 3-1 lists the 
messages. This section does not present all the SS7 messages that the UCS 
DMS-250 switch supports; it describes only the basic set of messages that 
affect RLT. 


For descriptions of specific RLT events and their messaging requirements, 
see the call examples in Chapter 4, “Common RLT call scenarios,” and 
Chapter 5, “RLT call scenarios for ESP.” 


Table 3-1 

SS7 ISUP RLT message summary 
Symbol Hex code Message name 
IAM 01 Initial Address Message 
ACM 06 Address Complete Message 
ANM 09 Answer Message 
FAR 1F Facility Request message (Note) 
FAA 20 Facility Accept message (Note) 

—continued— 
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Table 3-1 
SS7 ISUP RLT message summary (continued) 
Symbol Hex code Message name 
FRJ 21 Facility Reject message (Note) 
REL 0C Release message 
RLC 10 Release Complete message 
ote: [Ihe Facility Request , Facility Accept , and the Facility Reject 


(FRJ) messages are specific to the implementation of RLT. The UCS DMS-250 
switch does not require these messages to perform basic call setup using the 
Universal Carrier Protocol (UCP). 


—end— 


General message information 


In general, the ISUP messages implement RLT requirements. The ISUP 
messages for the UCS DMS-250 switching environment allow signaling to 
either request call-related information or invoke customer or network 
services. These messages also transfer user information through the network. 


This chapter presents the ISUP RLT messages and parameters graphically in 
the format defined in Figure 3-1. 
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Figure 3-1 
ISUP message format 


< Order of bit transmission 


Routing label 


Circuit identification code 
Message type 
Mandatory parameter A 


Mandatory 
fixed part 


Mandatory 
variable part 


Parameter P 
Parameter name X 


Optional 
part 


End of optional parameters 


Understanding ISUP message formats 


The type or length column in each of the tables in the following sections 
includes a key that defines the length of the ISUP message parameter. 
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The three possible parameter codes include the following: 
e F=Fixed-length parameters (mandatory) 


e V = Variable-length parameters (mandatory) 


e O= Fixed or variable length parameters (optional) 


Each message description includes an abbreviation (for example, IAM for 
Initial Address Message) after the full message name heading. Each 
description also includes a hexadecimal code and an equivalent binary code 
for the message. 


Directions of messages 

Some of the message descriptions include the terms forward and backward 
to indicate the direction in which the switches pass the messages. The term 
forward indicates that the switches send the message toward the call’s 
terminator, the called party. The term backward indicates that the switches 
send the message toward the call’s originator, the calling party. The switches 
pass most messages only forward or backward, but can pass Release (REL) 
and Release Complete (RLC) messages in either direction. 


Mandatory and optional status of ISUP message parameters 
Some parameters for ISUP messages are mandatory. Some ISUP messages 
also use optional parameters, depending on the message’s specific function. 
Each parameter description specifies the value for the length in bytes, 
defined as follows: 


e Fixed-length parameters specify the length, in bytes, of the parameter 
data. 


e Variable-length parameters specify the sum, in bytes, of the length of the 
length indicator (1 byte) plus the length of the parameter content. 


e Optional parameters specify the sum, in bytes, of the length of the 
parameter name (1 byte), the length of the length indicator (1 byte), and 
the length of the parameter content. 


Initial Address Message 
A UCS DMS-250 switch or services platform sends an Initial Address 
Message (IAM) forward to initiate seizure of an outgoing circuit. This 
message contains call handling and routing data. 


Message Type code 
The hexadecimal code for the IAM’s Message Type parameter is 01. 
Figure 3-2 shows the binary equivalent for the hexadecimal code. 
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Figure 3-2 


Binary code for the IAM’s Message Type parameter 


Parameters 


Table 3-2 shows the parameters of the IAM. 


Table 3-2 
IAM parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Nature of Connection Indicator F 1 byte See page 3-53 
Forward Call Indicator F 2 bytes See page 3-43 
Calling Party’s Category F 1 byte See page 3-23 
User Service Information V 3 bytes See page 3-72 
Called Party Number* V 3-11 bytes See page 3-19 
Calling Party Number* O 6-12 bytes See page 3-24 
Charge Number* O 3-9 bytes See page 3-37 
Generic Digits* ** O 2-130 bytes See page 3-45 
Forward Call Indicator O 4 bytes See page 3-43 
Multiple Business Group O 9 bytes See page 3-51 
Operator Information O 12 bytes See page 3-57 
Operator Service Indicator O 6 bytes See page 3-66 
Originating Line Information O 3 bytes See page 3-67 
Supplementary Line O 3 bytes See page 3-69 
Information* 
—continued— 
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Table 3-2 
IAM parameters (continued) 
Parameter name Type Length Description 
Transit Network Selector * ** O 5 bytes See page 3-70 
ote 1: unctionality involves the parameters marked by an asteris ; 


Note 2: The switch or services platform will not send certain parameters for 
non-operator RLT calls when the office parameter ALL_RLT_OPR_CALLS is set 
to N. This is true unless these parameters are received in an incoming IAM. 
These parameters are marked by a double asterisk (**). 


—end— 


Address Complete Message (ACM) 


A services platform or UCS DMS-250 switch sends the ACM backward to 
acknowledge reception of the address information it requires to route the call 
to the called party. 


Message Type code 
The hexadecimal code for the ACM’s Message Type parameter is 06. 
Figure 3-3 shows the binary equivalent for the hexadecimal code. 


Figure 3-3 
Binary code for ACM’s Message Type parameter 
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Parameters 
Table 3-3 provides a list of ACM parameters. 


Table 3-3 

ACM parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Backward Call Indicator F 2 bytes See page 3-14 
Call Reference” O 6 bytes See page 3-17 
Multiple Business Group O 9 bytes See page 3-51 
Note: RLT functionality involves the parameters marked by an asterisk (*). 


Answer Message (ANM) 


A services platform or UCS DMS-250 switch sends an ANM backward 
when the called party answers the call. 


Message Type code 


The hexadecimal code for an ANM Message Type parameter is 09. 
Figure 3-4 shows the binary equivalent for the hexadecimal code. 


Figure 3-4 
Binary code for an ANM Message Type parameter 
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Parameters 
Table 3-4 provides a list of ANM parameters the parameters of the ANM. 


Table 3-4 

ANM parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Network Specific Information O 6 bytes See page 3-55 
Call Reference* O 6 bytes See page 
Multiple Business Group O 9 bytes See page 3-51 
Operator Information* O 12 bytes See page 3-57 
Note: RLT functionality involves the parameters marked by an asterisk (*). 


Note: For a third-party interaction or operator callback call, a UCS 
DMS-250 switch can bridge a call even before receiving an ANM. 


Facility Request message 
The services platform sends a Facility Request (FAR) message backward to 
another exchange (switch) to request the activation of a facility (such as 
either an RLT bridging or RLT billing capability). After sending a FAR 
message, the switch waits for an FAA or FRJ response. 


Message Type code 


The hexadecimal code for a FAR message Message Type parameter is 1F. 
Figure 3-5 shows the binary equivalent for the hexadecimal code. 


Figure 3-5 
Binary code for a FAR message Message Type parameter 
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Parameters 
Table 3-5 provides a list of FAR message parameters. 


Table 3-5 

FAR message parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Facility Indicator* F 1 byte See page 3-41 
Called Party Number* O 3-14 bytes See page 3-19 
Call Reference* O 8 bytes See page 3-17 
Calling Party Number* O 4-14 bytes See page 3-24 
Charge Adjustment* O 8 bytes See page 3-34 
Charge Number* O 4-14 bytes See page 3-37 
Generic Digits* O 4-136 bytes See page 3-45 
Operator Information* O 14 bytes See page 3-57 
Originating Line Information* O 3 bytes See page 3-67 
Note: RLT functionality involves the parameters marked by an asterisk (*). 


Note 1: The FAR message is unique to RLT functionality; other features of 
the switch do not require it. 


Note 2: Optional parameters specify the sum in bytes of the length of the 
parameter name (1 byte), the length of the length indicator (1 byte), and the 
length of the parameter content. 


Facility Accept message 


A UCS DMS-250 switch sends an Facility Accept (FAA) message forward 
in response to a FAR message to indicate that it invoked the requested 
facility (such as either an RLT bridging or RLT billing capability). 


Message Type code 
The hexadecimal code for an FAA message Message Type parameter is 20. 
Figure 3-6 shows the binary equivalent for the hexadecimal code. 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


3-10 ISUP RLT messages and protocol 


Figure 3-6 
Binary code for an FAA message Message Type parameter 


Parameters 
Table 3-6 provides a list of FAA message parameters. 


Table 3-6 
FAA message parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Facility Indicator* F 1 byte See page 3-41 
Call Reference O 8 bytes See page 3-17 
Generic Digits O 4-136 bytes See page 3-45 
Note: RLT functionality involves the parameters marked by an asterisk (*). 


Note 1: The FAA message is unique to RLT functionality; other features of 
the switch do not require it. 


Note 2: Optional parameters specify the sum in bytes of the length of the 
parameter name (1 byte), the length of the length indicator (1 byte), and the 
length of the parameter content. 


Facility Reject message 


The switch sends an Facility Reject (FRJ) message forward in response to a 
FAR message to indicate that it could not perform the facility request. 


Message Type code 


The hexadecimal code for an FRJ message Message Type parameter is 21. 
Figure 3-7 shows the binary equivalent for the hexadecimal code. 
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Figure 3-7 
Binary code for an FRJ message Message Type parameter 


Parameters 
Table 3-7 provides a list of FRJ message parameters. 


Table 3-7 

FRJ message parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Facility Indicator* F 1 byte See page 3-41 
Cause Indicator* V 3 bytes See page 3-29 
Note: RLT functionality involves the parameters marked by an asterisk (*). 


Note: The FRJ message is unique to RLT functionality; other features of the 
switch do not require it. 


Release message 


The switch sends a Release (REL) message either forward or backward to 
indicate that it is releasing the circuit. The REL message defines the cause 
for the release. 


Message Type code 


The hexadecimal code for s REL message Message Type parameter is OC. 
Figure 3-8 shows the binary equivalent for the hexadecimal code. 
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Figure 3-8 
Binary code for REL message the parameters of the REL message 


Parameters 
Table 3-8 provides a list of REL message parameters. 


Table 3-8 

REL message parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Cause Indicator* V 3 bytes See page 3-29 
Note: RLT functionality involves the parameters marked by an asterisk (*). 


Release Complete message 


The switch returns an Release Complete (RLC) message either forward or 
backward to any switch from which it receives a REL message. An RLC 
message indicates that the switch performed the release. 


Message Type code 


The hexadecimal code for a RLC message Message Type parameter is 10. 
Figure 3-9 shows the binary equivalent for the hexadecimal code. 


Figure 3-9 
Binary code for a RLC message Message Type parameter 
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Parameters 
Table 3-9 provides a list of RLC message parameters. 


Table 3-9 

RLC message parameters 
Parameter name Type Length Description 
Message Type F 1 byte See page 3-50 
Cause Indicator* V 3 bytes See page 3-29 


Note: RLT functionality involves the parameters marked by an asterisk (*). 


SS7 ISUP message parameters required by RLT 


This section contains format and coding information for the ISUP message 
parameters that implement SS7 RLT. Table 3-10 lists the parameters. Each 
parameter description includes a hexadecimal code and an equivalent binary 
code for the message. 


Table 3-10 
SS7 ISUP RLT message parameter summary 
Hex Referenced by 
Parameter name code messages 
Backward Call Indicator 11 ACM 
Call Reference* 01 ACM, ANM, FAA, FAR 
Called Party Number* 04 IAM, FAR 
Calling Party Category* 09 IAM 
Calling Party Number* OA IAM, FAR 
Cause Indicator* 12 REL 
Charge Adjustment* 72 FAR 
Charge Number* EB FAR 
Facility Indicator* 18 FAA, FAR, FRJ 
Forward Call Indicator 07 IAM 
Generic Digits* C1 IAM, FAA, FAR 
Message Type Varies All messages 
—continued— 
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Table 3-10 
SS7 ISUP RLT message parameter summary (continued) 
Hex Referenced by 
Parameter name code messages 
Multiple Business Group C3 IAM, ACM, ANM 
Nature of Connection Indicator 06 IAM 
Network Specific Information FE ANM 
Operator Information” 70 IAM, ANM, FAR 
Operator Service Indicator 74 IAM 
Originating Line Information” EA IAM, FAR 
Supplementary Line Information” E4 IAM 
Transit Network Selector* 23 IAM 
User Service Information 1D IAM 
Note: RLT functionality involves the parameters marked by an asterisk (*). 
—end— 


Backward Call Indicator parameter 


The Backward Call Indicator parameter is a mandatory, fixed-length 
parameter in the ACM. It provides call information to tandem and remote 
switches. This parameter contains the following indicator codes: 


e charge indicator 

e called party’s status indicator 

e called party’s category indicator 
e end-to-end method indicator 

e interworking indicator 

e end-to-end information indicator 
e ISUP indicator 

e reverse holding indicator 


e ISDN access indicator 
Parameter code 


The hexadecimal code for the Backward Call Indicator parameter is 11. 
Figure 3-10 shows the binary equivalent for the hexadecimal code. 
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Figure 3-10 
Binary code for Backward Call Indicator parameter 


Parameter field 


Figure 3-11 illustrates the format of the Backward Call Indicator parameter 
field. 


Figure 3-11 
Format of the Backward Call Indicator parameter field 
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Table 3-11 describes the codes in the Backward Call Indicator parameter. 


Table 3-11 

Field codes for the Backward Call Indicator parameter 
Bits Codes and descriptions 
BA Charge indicator 


00 = no indication 
01 = no charge 


10 = charge 
11 = spare 
DC Called party’s status indicator 


00 = no indication 
01 = subscriber free 
10 = connect when free 


11 = spare 


FE Called party’s category indicator 
00 = no indication 
01 = ordinary (non-payphone) subscriber 
10 = payphone 
11 = spare 


HG End-to-end method indicator 
00 = no end-to-end method available 
01 = pass along method available 
10 = SCCP method available 
11 = pass along and SCCP methods available 


| Interworking indicator 
0 = no interworking encountered (SS7 all the way) 


1 = interworking encountered 


—continued— 
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Table 3-11 
Field codes for the Backward Call Indicator parameter (continued) 


Bits Codes and descriptions 


J end-to-end information indicator 
0 = no end-to-end information available 
1 = end-to-end information available 


K ISUP indicator 
0 = ISUP not used all the way 
1 = ISUP used all the way 


L Reverse holding indicator 
0 = reverse holding not required 
1 = reserved 


M ISDN access indicator 
0 = terminating access non-ISDN 
1 = terminating access ISDN 


N-P Reserved or spare (coded zero) 


—end— 


Call Reference parameter 


This optional parameter in ACM, ANM, FAA, and FAR messages conveys 
circuit-independent information that identifies a particular call. This 
parameter holds the call identity and the point code of the node (switch) for 
the call. 


The terminating switch passes this parameter back to the services platform 
in ANMs and ACMs. A switch will include this parameter in an ANM only 
if it did not receive an ACM with the call identity and point code. 


In a FAR message for a third-party interaction or operator-initiated call, 
the switches pass this parameter backward to the bridging UCS DMS-250 
switch to help it determine which calls to bridge together. 


As each intermediate tandem switch passes this parameter in an ANM or 
ACM, it replaces its own call identification and point code values with the 
values in this parameter. As each intermediate tandem switch passes this 
parameter in a FAR message, it replaces this parameter’s call identification 
and point code values with values received in an ANM or ACM. 
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Note: The host UCS DMS-250 switch does not add this parameter to 
ANMs; only an Enhanced Services Provider (ESP) with proper 
programming returns this parameter in ANMs. 


Parameter code 


The hexadecimal code for the Call Reference parameter is 01. Figure 3-12 
shows the binary equivalent for the hexadecimal code. 


Figure 3-12 
Binary code for Call Reference parameter 


Bits 


Call 
Reference 


Parameter field 
Figure 3-13 illustrates the format of the Call Reference parameter field. 


Figure 3-13 
Format of the Call Reference parameter field 


Bits 


Octet 1 
Call identity 
Octet 2 
Octet 3 Call identity 
Octet 4 


Octet 5 Point code 
Octet 6 
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Table 3-12 describes the codes in the Call Reference parameter. The UCS 
DMS-250 switch codes these fields at call time. 


Table 3-12 
Field codes for the Call Reference parameter 
Field Codes and descriptions 
Call identity The switch pads this 21-bit code to 24 bits. The switch 
assigns this code to uniquely identify a call. 
Point code Point code is the code of the signaling point in which the call 
is relevant. 
Note: For each subordinate field, the UCS DMS-250 switch sends the least 


significant octet first. 


Called Party Number parameter 


The Called Party Number parameter identifies the called party. It is a 
mandatory, variable-length parameter for the IAM. For a bridging FAR 
message, this parameter is optional. 


The UCS DMS-250 switch uses the Called Party Number parameter in an 
IAM to route and bill RLT calls. The value of the parameter is captured in 
the Called Number field of the CDR. In an IAM, this parameter also 
provides a nature of address value that indicates whether the call is 
operator-assisted and whether the switches have treated the call. 


For a redirected call, the remote UCS DMS-250 switch uses this parameter 
in a FAR message to translate and route the call. For both redirected and 
third-party transfer calls, the UCS DMS-250 switches copy the value of this 
parameter in a FAR message and add the value to the Called Number field in 
the operator services record (OSR) and CDR for the call. 


Note: If a bridging FAR message does not contain a Called Party Number 
parameter, the switch obtains billing information from the call’s CDR and 
includes it in the call’s OSR. 


Parameter code 
The hexadecimal code for the Called Party Number parameter is 04. 
Figure 3-14 shows the binary equivalent for the hexadecimal code. 
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Figure 3-14 
Binary code for the Called Party Number parameter 


Bits 


Called 
Party 
Number 


Parameter field 


Figure 3-15 illustrates the format of the Called Party Number parameter 
field. 


Figure 3-15 
Format of the Called Party Number parameter field 


Octet 1 

e e e ee 
Octet 2 ae 
Octet 3 


Octet 6 


Octet 7 


T [oe 
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Table 3-13 describes the codes in the Called Party Number parameter. 


Table 3-13 

Field codes for the Called Party Number parameter 
Field Codes and descriptions 
Odd/Even 0 indicates an even number of destination number (DN) digits. 
indicator 


1 indicates an odd number of DN digits. 


Nature of “0000101 = non-zero, national number, operator requested 
address 
indicator *0000110 = non-zero, international number, operator requested 


00000111-—1101111 = Spare 

1110000 = treated call 

1110001 = subscriber number, operator requested (0+) 
1110010 = national number, operator requested (0+) 
1110011 = international number, operator requested (01+) 
1110100 = no address present, operator requested 
1110101 = no address present, cut-through call to carrier 


1110110 = 950+ call from a local exchange carrier public station, 
hotel/motel line, or non-Equal Access End Office (EAEO). 


1110111 = test line test code 

1111000 to 1111110 = reserved for network-specific use 
1111111 = reserved 

Note: The UCS DMS-250 switches no longer use certain 
values for non-operator RLT calls when the office parameter 


ALL_RLT_OPR_CALLS is set to N. These values are marked 
by an asterisk (*). 


—continued— 
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Table 3-13 


Field codes for the Called Party Number parameter (continued) 


Field 


Numbering 
plan 
indicator 


D1-DN 
address 
information 


Codes and descriptions 


000 = unknown 
001 = ISDN numbering plan 
010 = telephony numbering plan 


011 to 111 = reserved 


The D1-DN address information field represents the digits of the 
destination number (DN). Each digit occupies four bits that are 
in binary code decimal (BCD) format. The digits start from D1 in 
the order dialed. For example, when 703-823-6279 is dialed, 
digit one equals 7, digit two equals 0, digit three equals 3, and 
so on. If the caller dials an odd number of digits, the switch 
inserts a filler code of 0000 after the last address digit. 


0000 = digit zero 
0001 = digit one 
0010 = digit two 
0011 = digit three 
0100 = digit four 
0101 = digit five 
0110 = digit six 
0111 = digit seven 
1000 = digit eight 
1001 = digit nine 
1010 = spare 
1011 = reserved 


1100 = reserved 


—continued— 
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Table 3-13 
Field codes for the Called Party Number parameter (continued) 
Field Codes and descriptions 
D1-DN 1101 = spare 
address 
information 1110 = spare 


(continued) 
1111 = reserved 


Note: With nature of address indicator codes of 1110100 (no 
address present, operator requested, 0-, 10XXX+0, or 00- call) 
or 1110101 (no address present, cut-through call to carrier), the 
message does not contain DN digits. The Called Party Number 
parameter contains only the first octet (#1) and omits the 
subsequent (#2-M) bytes. 


—end— 


Calling Party Category parameter 


The Calling Party Category parameter in the IAM indicates the category of 
the calling party. This fixed-length parameter is mandatory. 


Parameter code 


The hexadecimal code for the Calling Party Category parameter is 09. 
Figure 3-16 shows the binary equivalent for the hexadecimal code. 


Figure 3-16 
Binary code for Calling Party Category parameter 


Bits 


Calling 
Party 
Category 
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Parameter field 


Figure 3-17 illustrates the format of the Calling Party Category parameter 
field. 


Figure 3-17 
Format of the Calling Party Category parameter field 


Octet 1 Calling party category 


Table 3-14 describes the codes in the Calling Party Category parameter. 


Table 3-14 
Field codes for the Calling Party Category parameter 


Codes and descriptions 


00000000 Calling party category unknown* 


00001010 Ordinary calling subscriber (precedence level 1) 
00001101 test call 


Calling Party Number parameter 


The Calling Party Number provides information that identifies the calling 
party. The UCS DMS-250 switches include this optional parameter in the 
outgoing IAM for a per-trunk signaling (PTS) FGD call or a 
pseudo-automatic numbering identification (PAND) call to an ISUP IMT. 
Switches can also include this parameter in FAR messages. 


In an IAM, this parameter contains an automatic numbering identification 
(ANI) value. The UCS DMS-250 switches add the ANI value to the ANI 
Spill field in the CDR for the call. 


For both redirected and third-party transfer calls, the UCS DMS-250 
bridging switch copies the value of this parameter in a FAR message and 
adds the value to the Calling Number field in the OSR for the call. 


Note: If a FAR message does not contain a Calling Party Number 
parameter, the switch obtains billing information from the call’s CDR and 
includes it in the call’s OSR. 
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Parameter code 
The hexadecimal code for the Calling Party Number parameter is OA. 
Figure 3-18 shows the binary equivalent for the hexadecimal code. 


Figure 3-18 
Binary code for the Calling Party Number parameter 
Bits 
Calling 
Party 
Category 


Parameter field 
Figure 3-19 shows the format of the Calling Party Number parameter. 


Figure 3-19 
Format of the Calling Party Number parameter field 


Octet 1 Ra Nature of address indicator 


oo [ o | nereo par [reas] Senos 


Table 3-15 describes the codes in the Calling Party Number parameter. 
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Table 3-15 


Field codes for the Calling Party Number parameter 


Field 


Odd/Even 
indicator 


Nature of 
address 
indicator 


Codes and descriptions 


0 indicates an even number of DN digits. 


1 indicates an odd number of DN digits. 


0000000 = spare 

0000001 = subscriber number 

0000010 = spare; reserved for national use 

0000011 = national (significant) number 

0000100 = international number 

0000101 = non-zero, national number, operator requested 
0000110 = non-zero, international number, operator requested 
0000111-1101111 = spare 

1110000 = treated call 

1110001 = subscriber number, operator requested (0+) 
1110010 = national number, operator requested (0+) 
1110011 = international number, operator requested (01+) 
1110100 = no address present, operator requested 
1110101 = no address present, cut-through call to carrier 


1110110 = 950+ call from a local exchange carrier public 
station, hotel/motel line, or non-EAEO. 


1110111 = test line test code 
1111000 = PANI 
1111001 to 1111110 = reserved for network-specific use 


1111111 = reserved 


—continued— 
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Table 3-15 


Field codes for the Calling Party Number parameter (continued) 


Field 


Numbering 
plan 


Presentation 
Indicator 


Screening 


Codes and descriptions 


000 = unknown 
001 = ISDN numbering plan 
010 = telephony numbering plan 


011 to 111 = reserved 


The switch sets the Presentation Indicator to allow address 
presentation when a call originates on a PTS trunk and 
terminates to an ISUP IMT. If the call originates on an ISUP 
IMT and terminates to an ISUP IMT, the switch takes the 
value from the incoming IAM and codes it into the outgoing 
IAM. 

00 = address presentation allowed 

01 = address presentation restricted 

10 = address unavailable due to interworking 


11 = spare/reserved 

00 = user provided, not screened 

01 = user provided, screening passed 
10 = user provided, screening failed 


11 = network provided 


—continued— 
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Table 3-15 


Field codes for the Calling Party Number parameter (continued) 


Field 


DN address 
information 


Codes and descriptions 


The D1-DN address information field represents the digits 
of the DN. Each digit occupies four bits that are in BCD 
format. The digits start from D1 in the same order that they 
are dialed. For example, when 703-823-6279 is dialed, digit 
one equals 7, digit two equals 0, digit three equals 3 and so 
on. If the caller dials an odd number of digits, the switch 
inserts a filler code of 0000 after the last address signal. 
0000 = digit zero 

0001 = digit one 

0010 = digit two 

0011 = digit three 

0100 = digit four 

0101 = digit five 

0110 = digit six 

0111 = digit seven 

1000 = digit eight 

1001 = digit nine 

1010 = spare 

1011 = reserved 

1100 = reserved 

1101 = spare 

1110 = spare 


1111 = reserved 


—end— 
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Cause Indicator parameter 


The Cause Indicator parameter provides the coding standard, location, and 
cause value for the call. It also provides diagnostics, but the UCS DMS-250 
switch does not support diagnostics. This mandatory, variable-length 
parameter describes why the switch sent the REL, ACM, or FRJ message 
that contains it. This parameter also identifies the network that originated the 
message. 


In the FRJ message, this parameter defines why a switch could not perform 
the action that a FAR message requested. In REL and RLC messages, this 
parameter defines why the switches disconnected the call. 


Parameter code 
The hexadecimal code for the Cause Indicator parameter is 12. Figure 3-20 
shows the binary equivalent for the hexadecimal code. 


Figure 3-20 
Binary code for Cause Indicator parameter 


Bits 


Cause 
Indicator 


Parameter field 
Figure 3-21 illustrates the format of the Cause Indicator parameter field. 


Figure 3-21 
Format of the Cause Indicator field 


Bits 


pe trtets|si stats 


Octet 1 Ext Coding 


Cause value 


Octet 2 1 


Table 3-16 describes the codes in the Cause Indicator parameter field. 
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Table 3-16 


Field codes for the Cause Indicator parameter 


Field 


Extension 
indicator 


Octet 1 


Octet 2 


Coding 
standard 


General 
Location 


Codes and descriptions 


The extension indicator continues through the next octet. For 
example, octets 1 to 1a or 2 to 2a. If octet 1 or 2 is extended, the 
switch interprets the cause value as though it were 1111111. 


0 = octet continues through next octet 

1 = this octet is not extended 

0 = octet continues through next octet 

1 = this octet is not extended 

00 = CCITT standard 

01 = reserved 

10 = reserved 

11 = network-specific 

0000 = user 

0010 = local: local network in REL message 
0011 = transit (public) network in FRJ message 


1010 = unknown 


—continued— 
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Table 3-16 
Field codes for the Cause Indicator parameter (continued) 


Field Codes and descriptions 


Cause value Cause value has two fields: a class (bits 5 to 7) and a value 
within the class (bits 1 to 4). The decimal equivalent of the 
cause values are in parenthesis. All values belong to the CCITT 
standard set. 


Class 000 and 001 (normal event): 
0000001 = unallocated number (1) 
0000010 = no route to specified transit network (2) 
0000011 = no route to destination (3) 
0000100 = send special information tone (4) 
0000101 = incorrectly dialed trunk prefix (5) 
0010000 = normal clearing (16) 
0010001 = user busy (17) 
0010010 = no user responding (18) 
0010011 = no answer from user (19) 
0010101 = call rejected (21) 
0010110 = number changed (22) 
Cause 0011001 = translations fail ed(25) 
= g) 0011010 = call returns (26) 

0011011 = destination out of service (27) 

0011100 = address incomplete (28) 

0011101 = facility rejected (29) 

0011110 = apply locally (30) (proprietary) 

0011111 = normal, unspecified (31) 

a UCS DMS-250 switch interprets other values as 


—continued— 
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Table 3-16 


Field codes for the Cause Indicator parameter (continued) 


Field 


Cause 
value 
(continued) 


Codes and descriptions 


Class 010, resource unavailable: 

0100010 = no circuit available (34) 

0100110 = network out of order (38) 

0100111 = bridging failed due to reorigination failure (39) 
0101001 = temporary failure (41) 

0101010 = switching equipment congestion (42) 
0101011 = user information discarded (43) 

0101100 = requested channel not available (44) 
0101101 = preemption (45) 

0101110 = no preemption circuit available (46) 

0101111 = resource unavailable-unspecified (47) 

Note: Spare values are interpreted as if coded as 0101111. 
Class 011, service or option not available: 

0110001 = previous billing determination (31) 

0110100 = outgoing calls barred (52) 

0110101 = incompatible agents (53) 

0111001 = bearer capability not authorized (57) 

0111010 = bearer capability not implemented (58) 
0111111 = service/option not available-unspecified (63) 
Note: spare values are interpreted as if coded as 0111111. 
Class 100, service or option not implemented: 
1000001 = bearer capability not implemented (65) 
1000010 = channel type not implemented (66) 

1000101 = facility not implemented (69) 


1000110 = only restricted digital information bearer capability is 
available (70) 


1001111 = service or option not implemented (79) 


Note: Spare values are interpreted as if coded as 1001111. 


—continued— 
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Table 3-16 

Field codes for the Cause Indicator parameter (continued) 
Field Codes and descriptions 
Cause Class 101, invalid message (out of range): 
value 


(continued) 1010001 = invalid call reference value (81) 
1010111 = user not member of user group (87) 

1011000 = incompatible destination (88) 

1011111 = invalid message unspecified (95) 

Note: Spare values are interpreted as if coded as 1011111. 
Class 110, protocol error (unknown message): 

1100001 = message type non-existent or not implemented (97) 
1100011 = parameter non-existent or not implemented (99) 
1100100 = invalid parameter contents (100) 

1100111 = parameter not passed or not implemented (103) 
1101111 = protocol error, unspecified (111) 

Note: Spare values are interpreted as if coded as 1101111. 
Class 111, Interworking class: 

1111111 = interworking, unspecified (127) 


Note: Spare values are interpreted as if coded as 1111111. 


—end— 
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Charge Adjustment parameter 


The Charge Adjustment parameter contains billing information for a call 
after an operator or ESP has adjusted the charge. This information includes 
the charge adjust time of day, charge adjust type, charge adjust indicator, 
charge adjust amount, and charge adjust entry code. The UCS DMS-250 
switches add the information from this parameter to the Indic, Adjtype, 
Adjentry, Adjtime, and Adjamt fields in the OSR for the call. FAR messages 
include this optional parameter. 


Parameter code 
The hexadecimal code for the Charge Adjustment parameter is 72. 
Figure 3-22 shows the binary equivalent for the hexadecimal code. 


Figure 3-22 
Binary code for Charge Adjustment parameter 


Bits 


Parameter field 
Figure 3-23 illustrates the format of the Charge Adjustment parameter field. 
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Figure 3-23 
Format of the Charge Adjustment parameter field 


Table 3-17 describes the codes in the Charge Adjustment parameter. 


Table 3-17 
Field codes for the Charge Adjustment parameter 
Bits Codes and descriptions 
F-A Charge adjust time of day-minute 
6 bits range = 0-59 
H-G Charge adjust indicator 


00 = no indicator provided 

01 = minutes to be credited 

10 = dollars and cents to be credited 
11 = entire call to be credited 


M-I Charge adjust time of day-hour 
5 bits range = 0-23 
P-N 3 spare bits (coded as zero) 
—continued— 
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Table 3-17 


Field codes for the Charge Adjustment parameter (continued) 


Bits 


T-Q 


X-U 
L-Y 


n-m 


Codes and descriptions 


Charge adjust type 

0000 = wrong number 

0001 = cancel previous charge adjust 
0010 = poor transmission 
0011 = not used 

0100 = not used 

0101 = cut off call 

0110 = manually rated 

0111 = change billing 

1000 = walk away (future use) 
1001 = coin credit (future use) 
4 spare bits (coded as zero) 
Charge adjustment amount 
14 bits range = 0-9999 

In cents as: 0001-9999 

In minutes as: 00-99 

(followed by fillers) 

2 spare bits (coded as zero) 
Charge adjust entry code 

7 bits range = 0-127 

(Refer to call classification for a list of possible entry codes.) 


1 spare bit (coded as zero) 


—end— 
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Charge Number parameter 


The Charge Number parameter provides billing information to the UCS 
DMS-250 switch. This parameter can provide information for third-party, 
calling card, or credit card billing. UCS DMS-250 switches add this 
parameter’s information to the billnumb field in the OSR for the call. 


To make a UCS DMS-250 switch start timing a call for billing, a services 
platform sets the facility indicator in this optional parameter to “start time 
request” and sends a FAR message. 


In an IAM, this parameter also contains an automatic numbering 
identification (ANI) value. If the ANI is contained in this parameter, the 
switches add this value to the ANI SPILL field in the call’s CDR. If not, the 
switches get the ANI value from the Calling Party Number parameter. 


Parameter code 


The hexadecimal code for the Charge Number parameter is EB. Figure 3-24 
shows the binary equivalent for the hexadecimal code. 


Figure 3-24 
Binary code for the Charge Number parameter 


Charge 
Number 
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Parameter field 
Figure 3-25 illustrates the format of the Charge Number parameter. 


Figure 3-25 
Format of the Charge Number parameter field 


Octet 1 
A aT Pete ee 
Octet 3 


Octet 6 


Octet 7 
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Table 3-18 describes the codes in the Charge Number parameter field. 


Table 3-18 


Field codes for the Charge Number parameter 


Field 


Odd/Even 
indicator 


Nature of 
address 
indicator 


Codes and descriptions 


0 indicates an even number of DN digits. 
1 indicates an odd number of DN digits. 


(These values are coded at call time.) 


0000000 = spare 

0000001 = subscriber number 

0000010 = spare; reserved for national use 

0000011 = national (significant) number 

0000100 = international number 

0000101 = non-zero, national number, operator requested 
0000110 = non-zero, international number, operator requested 
0000111-1101111 = spare 

1110000 = treated call 


1110001 = subscriber number, operator requested (0+) 


1110010 = national number, operator requested (0+) 


1110011 = international number, operator requested (01+) 
1110100 = no address present, operator requested 
1110101 = no address present, cut-through call to carrier 


1110110 = 950+ call from a local exchange carrier public station, 
hotel or motel line, or non-Equal Access End Office (EAEO). 


1110111 = test line test code 

1111000 = Pseudo-ANI Information (PANI) 

1111001 to 1111110 = reserved for network-specific use 
1111111 = reserved 


—continued— 
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Table 3-18 


Field codes for the Charge Number parameter (continued) 


Field 


Numbering 
plan 
indicator 


DN address 
information 


Codes and descriptions 


000 = unknown 

001 = ISDN numbering plan 

010 = telephony numbering plan 

011 to 111 = reserved 

The D1-DN address information field represents the digits of the 


destination number. Each digit occupies four bits that are 
encoded in binary coded decimal (BCD) format. 


0000 = digit zero 
0001 = digit one 
0010 = digit two 
0011 = digit three 
0100 = digit four 
0101 = digit five 
0110 = digit six 
0111 = digit seven 
1000 = digit eight 
1001 = digit nine 
1010 = spare 
1011 = reserved 
1100 = reserved 
1101 = spare 
1110 = spare 


1111 = reserved 


—end— 
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Facility Indicator parameter 
The Facility Indicator parameter contains information that defines and 
controls RLT billing. FAR, FAA, and FRJ messages contain this mandatory, 
fixed-length parameter. This parameter defines the specific action that a FAR 
message requests at the bridging or remote UCS DMS-250 switch. The FAA 
and FRJ messages contain the same value to provide information. 


Parameter code 
The hexadecimal code for the Facility Indicator parameter is 18. Figure 3-26 
shows the binary equivalent for the hexadecimal code. 


Figure 3-26 
Binary code for Facility Indicator parameter 


Bits 


Facility 
Indicator 


Parameter field 
Figure 3-27 illustrates the format of the Facility Indicator parameter field. 


Figure 3-27 
Format of the Facility Indicator parameter field 


Octet 1 Facility Indicator 
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Table 3-19 describes the codes in the Facility Indicator parameter field. 


Table 3-19 


Field codes for the Facility Indicator parameter 


Value 


00011010 
00011011 
00010000 
*00010001 
00010010 
00010011 
00010100 
00010101 
00010111 
00011000 


(*). 


Codes and descriptions 


Context Block FAR 

Request Context Block FAR 

Release link for third-party interaction call 
Release link for operator redirect 
Request information from remote 

Start billing time 

Cancel billing time 

Restart billing at zero, no accumulation 
Billing information only 


Reorigination information only 


Note 1: Although it supports FAR messages with facility indicator values of 
“restart billing time” or “billing info only,” the UCS DMS—250 switch does not 
expect to receive them. 


Note 2: The host UCS DMS-250 switch supports these value when the office 
parameter, RLT_REDIRECT, is set to Y. These values are marked by an asterisk 
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Forward Call Indicator parameter 
The Forward Call Indicator parameter contains the following: 
e incoming international call indicator 


e end-to-end method indicator 

e interworking indicator 

e end-to-end information indicator 
e ISUP indicator 

e ISUP preference indicator 

e ISDN access indicator 

e SCCP method indicator 


The IAM contains this mandatory, fixed-length parameter. 


Parameter code 
The hexadecimal code for the Forward Call Indicator parameter is 07. 
Figure 3-28 shows the binary equivalent for the hexadecimal code. 


Figure 3-28 
Binary code for Forward Call Indicator parameter 


Call 
Indicator 


Parameter field 


Figure 3-29 illustrates the format of the Forward Call Indicator parameter 
field. 


Figure 3-29 
Format of the Forward Call Indicator field 


omae Lote tele pets p 
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Table 3-20 describes the codes in the Forward Call Indicator parameter field. 


Table 3-20 

Field codes for the Forward Call Indicator parameter 
Bit Codes and descriptions 
A National/international call indicator: 


0 = incoming national call 
1 = incoming international call 
C-B End-to-end method indicator: 
00 = no end-to-end method available 
01 = pass along method available 
10 = SCCP method available 
11 = pass along and SCCP methods available 
D Interworking indicator: 
0 = no interworking encountered (SS7 all the way) 


PRA to ISUP: no interworking if no interworking previously 
encountered 


1 = interworking encountered 
PTS to ISUP: interworking encountered 
E End-to-end information indicator: 
0 = no end-to-end information available 
1 = end-to-end information available 
F ISUP indicator: 
0 = ISUP not used all the way 
1 = ISUP used all the way 
H-G ISUP preference indicator: 
00 = ISUP preferred all the way (default) 
01 = ISUP not required all the way 
10 = ISUP required all the way 


11 = spare 


—continued— 
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Table 3-20 
Field codes for the Forward Call Indicator parameter (continued) 


Bit Codes and descriptions 


| ISDN access indicator: 
0 = originating access non-ISDN 
1 = originating access ISDN 

L-J Spare (coded as 0) 


P-M Reserved for national use (coded as 0) 


—end— 


Generic Digits parameter 


The Generic Digits parameter contains information in the form of digits 
pertaining to a supplementary service. It defines the type of digits it contains 
and includes encoding method indicators. Switches send this optional 
parameter in IAM, FAA, and FAR messages. 


Table 3-21 defines how the Generic Digits parameter varies for different 
messages and different call scenarios. 
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Table 3-21 


Generic Digits parameter for messages and scenarios 


Message Call scenario 


IAM Boomerang 
reorigination 


IAM XFROPSEL routing 


IAM All scenarios 


Description 


For reoriginated calls, the Generic Digits 
parameter contains a Call Identification 
(CALLID) value that identifies the 
previous call. The services platform 
sends the CALLID value in the ANM to 
the bridging UCS DMS-250 switch. For 
this scenario, a value of 00101 in the 
Type of Digits field defines the digits as 
the caller identity. The Generic Digits 
parameter contains the RLT context 
block available information and is used in 
the IAM message built on boomerang 
reorigination to let the Services Platform 
know that the UCS DMS-250 switch has 
a context block for the call, as well as 
information about the call’s state 
(0—originating, 1—talking, 2—disconnect) 
at the time of reorigination. 


The Generic Digits parameter specifies 
the queue for the host UCS DMS-250 
switch to use. For this scenario, a value 
of 01011 in the Type of Digits field 
defines the digits as the alternate queue. 


If the Nature of Address field in the IAM’s 
Called Party Number parameter 
indicates that the call requires treatment, 
the Generic Digits parameter specifies 
the type of treatment. For any scenario, 
a value of 01001 in the Type of Digits 
field defines the digits as the call 
treatment type. 


Note: For boomerang reorigination, the 
Generic Digits Parameter contains the 
call identity obtained from either the 
incoming FAR message or the Call 
Reference parameter of the ANM for the 
previous call. 


—continued— 
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Table 3-21 


Generic Digits parameter for messages and scenarios (continued) 


Message 


FAA 


Call scenario 


OGTSPKEY routing 


Description 


The Generic Digits parameter holds the 


contents of the CLDNO field from the 
remote switch’s OGTSPKEY table. For 
this scenario, a value of 00111 in the 
Type of Digits field defines the digits as 
the OGT called number. 


FAA, FAR 


FAR 


FAR 


Boomerang 
reorigination 


OGTSPKEY routing 


Redirect, third-party 
interaction, and 
operator call-back 


FAR, FAA Boomerang reorigination 
Generic Digits RLT context block is used 
by the FAR/FAA messages to hold the 
context block that is sent between the 
Services Platform and the UCS DMS-250 
switch. 


The Generic Digits parameter holds 
the OGT key number that the operator 
entered. For this scenario, a value of 
00110 in the Type of Digits field defines 
the digits as the OGT key number. 


The Generic Digits parameter contains 
the CALLID value that the services 
platform provided. The bridging switch 
places this value in the CALLID field of 
the OSR for the call and uses the value 
to match OSRs on both the host and 
bridging UCS DMS-250 switches. For 
this scenario, a value of 00101 in the 
Type of Digits field defines the digits as 
the caller identity. 


—end— 
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Parameter code 
The hexadecimal code for the Generic Digits parameter is C1. Figure 3-30 
shows the binary equivalent for the hexadecimal code. 


Figure 3-30 
Binary code for Generic Digits parameter 
Bits 
Generic 
Digits 


Parameter field 
Figure 3-31 illustrates the format of the Generic Digits field. 


Figure 3-31 
Format of the Generic Digits field 


pet rte} s|tsi steals | 


Octet 1 Encoding a 


Octet 2-N Generic digits 
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Table 3-22 describes the codes in the Generic Digits parameter field. 


Table 3-22 
Field codes for the Generic Digits parameter 


Field Codes and descriptions 

Encoding 000 = BCD even 

sereme 001 = BCD odd 
010 = IA5 
011 = binary 
110-111 = spare 

Type of 00000 = account code 

Digits 


00001 = authorization code (BCD) 

00010 = private networking classmark 

00011 = CLLI administration information (IA5) 
00100 = ANI index 

00101 = call ID (BIN) 

00110 = OGT key number (BIN) 

00111 = OGT called number (BCD) 

01000 = redirect information 

01001 = Terminating Switch ID and trunk group (BIN) 
01010 = RLT treatment code (BIN) 

01011 = alternate queue (BIN) 

01100 = call reference ID 

01101 = spare 


01110 = context Block 


—continued— 
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Table 3-22 
Field codes for the Generic Digits parameter (continued) 


Field Codes and descriptions 


Type of digits 10000 = originating switch ID and OGT 
10001 = IMT information (BCD even) 
10010 = hotel room number 
10011 = hotel guest name 
10100 = division identifier (BIN) 
10101 = trunk information 
10110 = 00Y 
11000 = transport information 
11001 = OPCHOICE index (BIN) 
11010 = BILLNUM (BCD) 

11011 = UNIVACC (BCD) 
11100 = PINDIGS (BCD) 

11101 = ACCTCD (BCD) 
11110 = context block available 
11111 = spare 


Generic 133 bytes containing the information that is appropriate for the 
digits type of digits. 


—end— 


Message Type parameter 


The Message Type parameter identifies the type of ISUP message. All SS7 
ISUP messages include this mandatory, fixed-length parameter. 


Parameter code 

Each type of ISUP message has a unique hexadecimal code that defines its 
type. For example, the hexadecimal code for FAR messages is 1F. The 
message descriptions earlier in this section define the hexadecimal code for 
each Message Type parameter. 


Parameter field 
Figure 3-32 illustrates the format of the Message Type parameter field. 
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Figure 3-32 
Format of the Message Type parameter field 


Octet 1 Message Type 


Table 3-23 describes the codes in the Message Type parameter. 


Table 3-23 
Field codes for the Message Type parameter 


Value Descriptions and codes 


00000001 IAM (01) 
00000110 ACM (06) 
00001001 ANM (09) 
00011111 FAR message (1F) 
00100000 FAA message (20 
00100001 FRJ message (21 
00000011 REL message (0C) 
00010000 RLC message (10) 


) 
) 


( 
( 


Multiple Business Group parameter 


If the MBGXLA option for the ISUP IMT is Y, the switch sends a Multiple 
Business Group parameter in the IAM. Switches include it in ACMs and 
ANMsSs as well as IAMs. 


Parameter code 
The hexadecimal code for the Multiple Business Group parameter is C3. 
Figure 3-33 shows the binary equivalent for the hexadecimal code. 
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Figure 3-33 
Binary code for Multiple Business Group parameter 


Multiple 
Business 
Group 


Parameter field 


Figure 3-34 illustrates the format of the Multiple Business Group parameter 
field. 


Figure 3-34 
Format of the Multiple Business Group parameter field 


Bits 


pet rts} stats} ati 
Octet 2 Length 


Octet 3 
N k ID 
Octet 4 Siwar 
Ra Network Cust G ID 
Octet 6 etwork Customer Group 


Octet 7 Line Privileges Indicator 
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Table 3-24 describes the codes in the Multiple Business Group parameter 


field. 
Table 3-24 
Field codes for Multiple Business Group parameter 

Field Codes and descriptions 

Party 0000 = NETINFO calling party 

selection 

code 

Spare 0000 = spare 

Length 00000101 = length is always five 

Network ID 2 octets containing the value from the NETID field in the 

NETNAMES table 

Network 2 octets containing a value representing the Centrex 

customer customer group from the NETCGID field in the CUSTNTWK 

group ID table 

Line 1 octet containing a value representing NCOS from the 

privileges NETTOSTS and STSTONET tables 

indicator 


Nature of Connection Indicator parameter 


The Nature of Connection Indicator parameter contains the satellite 
indicator, continuity check indicator, and echo control device indicator. 
Switches send this mandatory, fixed-length parameter in the IAM. 


Parameter code 


The hexadecimal code for the Nature of Connection Indicator parameter is 
06. Figure 3-35 shows the binary equivalent for the hexadecimal code. 


Figure 3-35 
Binary code for Nature of Connection Indicator parameter 


Nature of 
Connection 
Indicator 
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Parameter field 
Figure 3-36 illustrates the format of the Nature of Connection Indicator 


parameter field. 


Figure 3-36 


Format of the Nature of Connection Indicator parameter field 


Octet 1 


Bits 


Table 3-25 describes the codes in the Nature of Connection Indicator 


parameter. 


Table 3-25 


Field codes for the Nature of Connection Indicator parameter 


Bit 


BA 


DC 


H-F 


Codes and descriptions 


Satellite indicator: 
00 = no satellite circuit in the connection 


01 = one satellite circuit in the connection. (This default value is 
set if table TRKSGRP’s datafill for the terminator has the SAT 
field set to Y.) 


Continuity check indicator (coded at call time based on datafill in 
TRKSGRP table): 


00 = continuity check not required 

01 = continuity check required on this circuit 

10 = continuity check performed on previous circuit 
11 = spare 

Echo suppressor indicator: 

0 =N in table TRKSGRP 

1 =H in table TRKSGRP 

Unused: 


000 = spare (coded as 0) 


297-2621-345 Standard 04.02 November 1999 


ISUP RLT messages and protocol 3-55 


Network-specific Information parameter 


The Network-specific Information parameter contains a completion code, 
answer type, trunk group number, and switch ID. Switches send this 
mandatory, fixed-length parameter in an ANM. 


Parameter code 


The hexadecimal code for the Network-specific Information parameter is 
FE. Figure 3-37 shows the binary equivalent for the hexadecimal code. 


Figure 3-37 
Binary code for Network-specific Information parameter 


Bits 


Network 
Specific 
Information 


Parameter field 


Figure 3-38 illustrates the format of the Network-specific Information 
parameter field. 


Figure 3-38 
Format of the Network-specific Information parameter field 


Bits 


pe} 7tets | si steati 
Completion code Answer type 
Trkgrp number 


Spare Switch ID 
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Table 3-26 describes the codes in the Network-specific Information 
parameter. 


Table 3-26 
Field codes for the nature of the Network-specific Information parameter 


Field Codes and descriptions 


Answer type 0000 = nil answer 
0001 = software, no voice detected 
0010 = software, voice detected 
0011 = software, ring detected 
0100 = non-IMT hardware answer 
0101 = software silence 
0110 = undefined 
0111 = audio tone detector hardware failure 
1000 = software, busy tone detected 
1001 = software, reorder tone detected 
1010 = IMT software answer 
1011 = IMT hardware answer 


1100-1111 = spare 


Completion 0000 = normal call 


code 
0001 = off-net route advance invoked 
Final Switch ID = 0-127 
terminating 
trunk Trunk group number = 0—4095 
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Operator Information parameter 


The Operator Information parameter contains information about the 
answering agent. Switches send this optional parameter in IAMs, ANMs, 
and FAR messages. Specifically, this parameter provides operator 
information to the bridging UCS DMS-250 switch, which places the 
information in the OPERNUMB, TRBLCODE, and ENTCODE fields of the 
OSR for the call. 


Note: In an ANM, this parameter’s Reorigination Type field determines 
what type of reorigination a UCS DMS-250 switch can perform for the call. 


Parameter code 
The hexadecimal code for the Operator Information parameter is 70. 
Figure 3-39 shows the binary equivalent for the hexadecimal code. 


Figure 3-39 
Binary code for Operator Information parameter 


Bits 


Operator 
Information 
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Parameter field 


Figure 3-40 illustrates the format of the Operator Information parameter 
field. 


Figure 3-40 
Format of the Operator Information parameter field 


Octet 1 Operator number 


Reorigination 
Octet 2 Operator number 
Octet 3 | OPR | Entry code 


Octet 4 Trouble indicator 


Octet5 | opp, | Bridge l 
EVEN |Reorig. Action response 
Control 


Octet 6 Term route code Feat code 


Octet 7 ANM Billing 


Indicator 


Octet 8 |Reorig Allowed} SLR. STR key duration at talking* 


Octet 9 Spare Immed* STR key duration at non-talking* 


Octet 11 Supplementary Digits Supplementary Digits 


Octet 12 Spare 


UTR Digit* Reorigination trigger type* 


Note: The fields denoted by an asterisk (*) are only valid when the 
REORIGINATION_TYPE field is 11. The Operator Information parameter 
includes these fields only for the Reorigination FAR, Redirecting FAR, and 
Bridging FAR. 


Table 3-27 describes the codes in the Operator Information parameter field. 
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Table 3-27 

Field codes for the Operator Information parameter 
Field Codes and Descriptions 
Operator number Operator number range: 0—4096 


Reorigination type type of reorigination behavior for the call 
00 = the originator receives a dial tone 


01 = the switch uses the originally dialed number to 
immediately translate and route the reoriginated call 
(boomerang reorigination) 


10 = this value prevents the switch from reoriginating call 

11 = reorigination Type 

Note: The Operator Information parameter includes the 

Reorigination Type field only for ANMs and FAR 

messages, and only when the switch includes the 

Enhanced Reorigination for Operator Services feature 

(ENSRO0002) in the ON state; otherwise, the field is spare. 
Entry code Indicates the charge class that the operator entered: 

0000000 = default (00) 

0000001 = operator-initiated Call (01) 

0010100 = station paid, operator-assisted (20) 

0010110 = station special calling (22) 

0010111 = person paid (23) 

0011001 = person special calling (25) 

0101000 = station paid overseas, international (40) 

0111100 = station paid, operator-assisted (60) 

0111110 = station special calling, international (62) 

0111111 = person paid, international (63) 

1000001 = person special calling, international (65) 

Note: Other entry codes do not affect RLT functionality. 


OPR A one-bit indicator for operator reorigination (OPR) 
indicator 


—continued— 
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Table 3-27 
Field codes for the Operator Information parameter (continued) 
Field Codes and Descriptions 
Trouble Indicates type of operator trouble: 
indicator 
0000 = none 


0001 to 1111 = spare 


TAC A one-bit time and charge (TAC) request indicator: 
0 = no request 


1 = time and charge requested 


Action response Code for operator action response information 
Bridge Reorig Specifies whether or not the bridging switch bridges the 
Control call regardless of the result of allocation of reorigination 


resources based on the other reorigination fields. 


0 = The reorigination resources allocation has no impact 
on bridging the call. The call is to be bridged even if the 
switch fails to allocate the resources for reorigination (N). 


1 = The call will not be bridged if the resources could not 
be successfully setup (Y). 


Note: This field is part of the reorigination fields; therefore 
if the Reorigination Type field is not 11, this field is not 


used. 

Odd/Even Indicates an odd or even number of nibbles 

Feat code Indicates the operator information feature code 

Term route code Code for operator’s terminator routes 

ANM Billing Indi- 00 = (Default) No external control; 

cator RLT_FIRST_ANM_BILLING determines first- or last-ANM 
billing. 


01 = external control; bill from first ANM 
10 = external control; bill from last ANM 


11 = spare 


—continued— 


297-2621-345 Standard 04.02 November 1999 


ISUP RLT messages and protocol 3-61 


Table 3-27 
Field codes for the Operator Information parameter (continued) 


Field Codes and Descriptions 


Reorigination Trig- Specifies when and how to invoke call reorigination. 


geriypa If the originating trunk of the call in the Origination switch 


is anon-AXXESS trunk, such as DAL, FGA, FGB, FGC, 
PTS FGD or SS7 FGD: 


0000 = as provisioned at the Originating switch (0) 
0001 = AUTO (1) 

0010 = MANUAL (2) 

0001 — 1111 = not supported (3—15) 

Note: This field is part of the reorigination fields; if the 
Reorigination Type field is not 11, this field is not used. 


Note: AUTO identifies that reorigination occurs 
automatically after disconnect of the called party. MANUAL 
identifies that reorigination occurs only if the octathorpe 
key (#) is pressed during the ringing state of the call, the 
talking state (for using STR only), or within the time 
specified by the field PSPDSEIZ in table TRKSGRP after 
called party disconnects. The receiver used to scan the 
octathorpe key is identified by the REORIG_RECEIVERS 
office parameter in table OFCVAR. 


The following codes apply if the originating trunk of the call 
in the Originating switch is an AXXESS trunk: 
0000 = as provisioned at the Originating switch (0) 
0001 = ONDISC (1) 

0010 = ONKEY STR and UTR (2) 

0011 = ONKEY STR (8) 

0100 = ONKEY UTR (4) 

0101 = ONKEY STR and ONDISC (5) 

0110 = ONKEY UTR and ONDISC (6) 

0111 = ONKEY STR and UTR and ONDISC (7) 
1000 — 1111 = not supported (8-15) 


—continued— 
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Table 3-27 


Field codes for the Operator Information parameter (continued) 


Field 


UTR Digit 


STR Key Duration 
at Talking 


Codes and Descriptions 


Note: ONDISC identifies that reorigination occurs 
immediately after disconnect of the called party or 
following expiration of the delay timer identified by the 
Disconnect Timer field. ONKEY identifies that reorigination 
occurs when the reorigination key is pressed during the 
ringing state of the call, the talking state (for STR only), or 
within the time specified by the Disconnect Timer value 
after called party disconnect occurs. STR and UTR are the 
receivers used to scan and detect when the reorigination 
key is pressed. 


Specifies the digit that is to be pressed in order to 
reoriginate the call when using a UTR receiver. 


00 = represents one asterisk digit (*) (S) 

01 = represents two asterisk digit (**) (SS) 

10 = represents one octathorpe digit (#) (P) 

00 = spare 

Note: |f Reorigination Trigger Type is not used or does 
not specify ONKEY UTR, this field is not used. 


Note: This field is part of the reorigination fields; if 
Reoriginating type is not 11, this field is not used. 


Note: |f the originating trunk of the call in the Originating 
switch is a non-AXXESS trunk, this field is not used. The 
only reorigination digit allowed for non-AXXESS trunks is 
the octathorpe digit (#). 


Specifies the length of time in 100ms increments that the 
reorigination digit must be pressed in order to reoriginate 
the call when using an STR receiver during the talking 
state of the call. Range is 0 to 31. 


Note: |f Reorigination Trigger Type is not used or does 
not specify ONKEY STR, this field is not used. 


Note: This field is part of the reorigination fields; if 
Reoriginating type is not 11, this field is not used. 


—continued— 
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Table 3-27 
Field codes for the Operator Information parameter (continued) 
Field Codes and Descriptions 
STR Digit Specifies the digit that is to be pressed in order to 


reoriginate the call when using an STR receiver. 

0 = represents one asterisk digit (*) (S) 

1 = represents one octathorpe digit (#) (P) 

Note: If Reorigination Trigger Type is not used or does 
not specify ONKEY STR, this field is not used. 


Note: This field is part of the reorigination fields; if 
Reoriginating type is not 11, this field is not used. 


Note: |f the originating trunk of the call in the Originating 
switch is a non-AXXESS trunk, this field is not used as the 
only reorigination digit allowed for non-AXXESS trunks is 
the octathorpe digit (#). 


Reorig Allowed Specifies the reorigination type allowed. 


00 = no change to the reorigination type allowed at the 
Origination switch 


01 =normal reorigination allowed 

10 = boomerang reorigination allowed 

11 = spare 

Note: This field is part of the reorigination fields; if 
Reoriginating type is not 11, this field is not used. 


Note: Boomerang reorigination will not occur unless the 

ENSR0002 “ENSR Enhanced Reorig” SOC is in the ON 

state; otherwise, the value 10 boomerang reorigination is 
processed as same as the value 01 normal reorigination. 


—continued— 
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Table 3-27 


Field codes for the Operator Information parameter (continued) 


Field 


STR Key Duration 
at non-Talking 


Immed 


Codes and Descriptions 


Specifies the length of time in 100ms increments that the 
reorigination digit must be pressed in order to reoriginate 
the call when using an STR receiver during the non-talking 
state of the call. Range is 1 to 31. 


Note: |f Reorigination Trigger Type is not used or does 
not specify ONKEY STR, this field is not used. 


Note: This field is part of the reorigination fields; if 
Reoriginating type is not 11, this field is not used. 


Note: If the originating trunk of the call in the Originating 
switch is a non-AXXESS trunk, this field is not used 
because the REORIG_DIGIT_DURATION office 
parameter has specified the STR reorigination key 
duration used for non-AXXESS trunk groups. 


Specifies if the reorigination is to immediately occur upon 
called party disconnect or delay a period of time. 


0 = disconnect timer delays automatic triggering of 
reorigination (N) 


1 = reorigination immediately occurs upon called party 
disconnected (Y) 


Note: |f Reorigination Trigger Type is not used or does 
not specify ONDISC, this field is not used. 


Note: This field is part of the reorigination fields; if 
Reoriginating type is not 11, this field is not used. 


Note: If the originating trunk of the call in the Originating 
switch is a non-AXXESS trunk, this field is not used. This 
occurs because for non-AXXESS trunks, the reorigination 
occurs immediately after the called party disconnected 
when Reorigination Trigger Type is AUTO. 


—continued— 
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Table 3-27 
Field codes for the Operator Information parameter (continued) 
Field Codes and Descriptions 
Disconnect Timer For ONKEY, this field represents the amount of time in 


seconds that the subscriber has to press the reorigination 
digit to reoriginate a call after the called party disconnects. 


If reorigination ONDISC is enabled and Immed is 0, this 
field identifies the amount of time to delay after called 
party disconnect before reorigination automatically occurs. 
For example, this timer value marks the transition from 
ONKEY to ONDISC reorigination support. Range is 0-31. 


Note: |f Reorigination Trigger Type is 0000 or spare, this 
field is not used. 


Note: This field is part of the reorigination fields; if 
Reoriginating type is not 11, this field is not used. 


Note: |f the originating trunk of the call in the Originating 
switch is a non-AXXESS trunk, this field is not used 
because the field PSPDSEIZ in the table TRKSGRP 
provides the timer value for non-AXXESS trunk groups. 


Spare These are spare bits for optional use in future releases. 


—end— 
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Operator Service Indicator parameter 
The Operator Service Indicator parameter is an optional IAM parameter. 
When a call’s terminator is an ISUP IMT with RLT capability, a UCS 
DMS-250 switch includes this parameter in an outgoing IAM to another 
UCS DMS-250 switch. This parameter indicates that a call requires the 
switch to perform a charge rating lookup operation based on information 
(such as the ANICLAS and PANICLAS fields) in the originating trunk 
group. 


Parameter code 


The hexadecimal code for the Operator Service Indicator parameter is 74. 
Figure 3-41 shows the binary equivalent for the hexadecimal code. 


Figure 3-41 
Binary code for the Operator Service Indicator parameter 


Bits 


Operator 
Service 
Indicator 


Parameter field 


Figure 3-42 illustrates the format of the Operator Service Indicator 
parameter field. 


Figure 3-42 
Format of the Operator Service Indicator parameter field 


Bits 


Octet 1 


Octet 2 
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Table 3-28 describes the codes in the Operator Service Indicator parameter. 


Table 3-28 

Field codes for Operator Service Indicator parameter 
Field Codes and descriptions 
Service 0000000 = default 
indicator 


0000001 = charge rating 
0000010 to 1111111 = spare 


Rating 00 = no rating 
01 = auto rating 
10 = spare 
11 = spare 


Originating Line Information parameter 
The UCS DMS-250 switch encodes the Originating Line Information 
parameter only when origination occurs on an FGD, FGB, FGC, or 
pseudo-ANI (PANI) call. Switches include this optional parameter in IAM 
and FAR messages. The parameter is one byte long. 


When a UCS DMS-250 switch receives this parameter in a FAR message, 
the information is captured in the SERVFEAT field of the OSR for the call. 


Parameter code 


The hexadecimal code for the Originating Line Information parameter is 
EA. Figure 3-43 shows the binary equivalent for the hexadecimal code. 


Figure 3-43 
Binary code for Originating Line Information parameter 
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Parameter field 


Figure 3-44 illustrates the format of the Originating Line Information 
parameter field. 


Figure 3-44 


Format of the Originating Line Information parameter field 


Octet 1 


Originating Line Information 


Table 3-29 describes the codes in the Originating Line Information 


parameter. 


Table 3-29 


Field codes for Originating Line Information parameter 


Value Description Code 
DTMF: 
00000000 Identified line, no special treatment (00) 
00000001 ONI Multiparty (01) 
00000010 ANI failure (unavailable) (02) 
00000110 Hotel without room identification (06) 
00000111 + Coinless, hospital, or inmate (07) 
00001000 InterLATA restricted (08) 
00010100 AIOD (listed DN sent) (14) 
00011011 Coin line (1B) 
01000100 InterLATA restricted (hotel) (44) 
01001110  InterLATA restricted (coinless) (4E) 
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Supplementary Line Information parameter 


The Supplementary Line Information parameter in an IAM instructs a switch 
to include a Call Reference parameter in the ACM or ANM. Switches 
include this optional parameter when the services platform can request RLT 
bridging. 


In an IAM message for a third-party interaction or services platform 


callback call, this parameter performs either of the following functions: 
e identifies the call as a callback 


e indicates that the receiving switch must include a Call Reference 
parameter in the ACM or ANM (if the switch does not send an ACM) 


Parameter code 
The hexadecimal code for the Supplementary Line Information parameter is 
E4. Figure 3-45 shows the binary equivalent for the hexadecimal code. 


Figure 3-45 
Binary code for Supplementary Line Information parameter 


Parameter field 
Figure 3-46 illustrates the format of the Supplementary Line Information 
parameter field. 


Figure 3-46 
Format of the Supplementary Line Information parameter field 


Octet 1 Supplementary Line Information 
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Table 3-30 describes the codes in the Supplementary Line Information 
parameter. 


Table 3-30 
Field codes for Supplementary Line Information parameter 


Codes and descriptions 


11111000 RLT call operation 
11111001 RLT call back call 


Transit Network Selector parameter 


The Transit Network Selector parameter identifies the networks that the 
switch requested to route the call. The parameter defines the type of 
network, the network ID plan, and the network ID. Switches send this 
optional parameter in the IAM. 


This parameter’s Reoriginated Call field identifies whether the call is a 

boomerang reorigination (that is, whether the switches used the original 
dialed number to translate and route the call). For an explanation of the 

boomerang origination scenario, see Chapter 5, “RLT call scenarios for 
ESP.” 


Parameter code 


The hexadecimal code for the Transit Network Selector parameter is 23. 
Figure 3-47 shows the binary equivalent for the hexadecimal code. 


Figure 3-47 
Binary code for Transit Network Selector parameter 


Transit 
Network 
Selector 
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Parameter field 


Figure 3-48 illustrates the format of the Transit Network Selector parameter 
field. 


Figure 3-48 
Format of the Transit Network Selector parameter field 


Bits 


8e | 7{]e;s{af] 3] 2ii_ 


Table 3-31 describes the codes in the Transit Network Selector parameter. 


Table 3-31 
Field codes for Transit Network Selector parameter 


Field Codes and descriptions 


Reoriginated 0 = a switch either did not reoriginate the call or reoriginated it. 
Call 


1 = a switch used the originally dialed number to immediately 
translate and route the reoriginated call (boomerang 
reorigination). 

Note: The Transit Network Selector parameter includes the 
Reoriginated Call field only in IAMs, and only when the UCS 
DMS-250 switch includes the Enhanced Reorigination for 
Operator Services feature (ENSR0002); otherwise, the field is 
spare. 


Network ID 000 = CCITT-standardized identification 


type 010 = national network identification 


Network ID 0000 = unknown 
pian 0001 = carrier Identification Code (CIC) with Circuit Code 
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Table 3-31 

Field codes for Transit Network Selector parameter 
Field Codes and descriptions 
Digits 1-3 BCD equivalent of the CIC 


Circuit code 0000 = unspecified 
0001 to 0111 = spare (coded as zero) 


1000 to 1111 = reserved for network specific use 


User Service Information parameter 


The User Service Information parameter defines the calling party’s request 
for bearer capability. It includes the following call requirements: 


e coding standard 
e information transfer capability 
e transfer mode 


e information transfer rate 


Switches send this mandatory, variable-length parameter in an IAM. 


Parameter code 


The hexadecimal code for the User Service Information parameter is 1D. 
Figure 3-49 shows the binary equivalent for the hexadecimal code. 


Figure 3-49 
Binary code for User Service Information parameter 


Bits 


User 
Service 
Information 
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Parameter field 


Figure 3-50 illustrates the format of the User Service Information parameter 
field. 


Figure 3-50 
Format of the User Service Information parameter field 


Bits 


pet 7teoet stats] 2ti 


Octet 1 Coding standard Information transfer capability 
Octet 2 Information transfer rate 


Table 3-32 describes the codes in the User Service Information parameter. 


Table 3-32 
Field codes for User Service Information parameter 


Codes and descriptions 


Coding 00 = CCITT-standardized 
standard 01 = reserved for international 
10 = national standard 


11 = reserved 


Information 00000 = speech 
transfer 
capability 


Extension bit 0 = octet continues through next octet 


1 = this is the last octet 
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Table 3-32 
Field codes for User Service Information parameter 


Field Codes and descriptions 


Transfer 00 = Circuit mode 
maoae 01 = reserved 
10 = Packet mode 


11 = reserved 


Information 00000 = Channel size 
wanster tate: ogopa kbi 
10011 = 384 kbit/s 
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Common RLT call scenarios 


This chapter summarizes the flow of Signaling System 7 (SS7) Integrated 
Services Digital Network (ISDN) User Part (ISUP) messages between UCS 
DMS-250 switches and a services platform that supports Release Link Trunk 
(RLT) capabilities. An Enhanced Services Provider (ESP) is a services 
platform. 


An ESP is a software system that provides specialized switching, billing, 
and call processing features. 


This chapter provides high-level diagrams and message flow diagrams for 
each of the common RLT call scenarios. Each message flow diagram 
illustrates the SS7 ISUP messaging between a bridging UCS DMS-250 
switch, a remote UCS DMS-250 switch, and a services platform. The 
message flow diagrams highlight parameters that the ISUP messages 
contain. For technical descriptions of messages and parameters, refer to 
Chapter 3, “SS7 ISUP RLT messages and protocol.” 


Note: The remote switch shown in the diagrams can also be the bridging 
switch under the proper conditions. For clarity, however, the bridging and 
remote switches in this chapter’s explanations are not the same switch. Even 
when the remote switch is the bridging switch, each scenario remains 
essentially the same. 
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The scenarios do not explain how a UCS DMS-250 switch generates billing 
records for each RLT call. For billing information, refer to Chapter 7, 
“Billing for RLT calls.” 

The following RLT call scenarios are described in this chapter: 

e services platform redirect and transfer 

e third-party interaction 

e services platform-initiated call back 

e reorigination scenario with bridging at originating switch 

e reorigination scenario with bridging not at originating or services 


platform 


Services platform redirect and transfer scenario 


In this scenario, the services platform transfers the call to its destination and 
requests release link trunking. After the appropriate switch bridges the call, 
the release link trunking capability frees the services platform and the 
remote switch. 


The trunks connecting the bridging switch, the remote switch, and each 
services platform is an ISUP intermachine trunk (IMT) with RLT 
functionality. The trunk connecting the caller to the bridging switch is one of 
the following: 


e aper-trunk signaling (PTS) trunk 

e aprimary rate interface (PRI) trunk 

e an ISUP FGD trunk 

e an ISUP IMT without RLT functionality 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 


Figure 4-1 is a high-level diagram of the services platform redirect and 
transfer scenario. 
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Figure 4-1 
Services platform redirect and transfer scenario 


(1) Customer originates call; switches route call to services platform 


Bridging Remote Services platform 


switch switch 


Bridging Remote 
switch switch 


-aas Services platform 
Bridging Remote i 


switch switch 


Legend 


First leg of call Te 
— 
«-———— Second leg of call | Bridging 
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Message flow for redirect and transfer scenario 


Figure 4-2 is a comprehensive message flow diagram for the redirect and 
transfer scenario. It shows the sequence for the exchange of messages and 
parameters between the bridging switch, the remote switch, and the services 
platform. 


Specifically, the message exchange occurs as follows: 


1 


A switch, the bridging switch in this scenario, receives the call. Based on 
the nature of the call, the bridging switch formats an Initial Address 
Message (IAM) and sends it to another switch, the remote switch in this 
scenario. 


Note: If the call is an NOO services (700, 800, or 900) call, the switch 
performs NOO lookup (that is, it translates the NOO services call into a 
ten-digit number). The switch places the NOO number in the CDR’s 
Dialed Number field and places the ten-digit number into the CDR’s 
Called Number field. 


In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 4-1 shows parameters 
in this IAM that affect RLT functionality. 


Table 4-1 
RLT parameters in the IAM 


RLT parameter Comments 


Called Party Number The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides a Nature of Address 
(NOA) value that indicates whether the call is 
operator-assisted or whether the switch must treat 
the call. 


Calling Party Number This parameter contains an ANI value. The 
switches add this value to the ANI SPILL field in 
the call’s CDR, unless they pull the ANI value from 
the Charge Number parameter. 


Charge Number This parameter contains an automatic numbering 
identification (ANI) value. If the IAM contains this 
parameter, the switches add this value to the ANI 
SPILL field in the call’s CDR. 


—continued— 
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Table 4-1 

RLT parameters in the IAM (continued) 
RLT parameter Commenis 
Charge Number If the IAM does not contain this parameter, the 
(continued) switches get the ANI value from the Calling Party 


Number parameter. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLTO002). 


—end— 


3 The services platform returns an Address Complete Message (ACM) to 
the remote switch. The ACM confirms that the services platform 
received the information needed to route the call to its destination. The 
remote switch passes the ACM to the bridging switch. 


4 When an ESP operator answers the call, the ESP sends an Answer 
Message (ANM) to the remote switch. The remote switch formats and 
sends another ANM to the bridging switch. Table 4-2 shows parameters 
in this ANM that affect RLT functionality. 
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Table 4-2 
RLT parameters in the ANM 
RLT parameter Comments 
Call Reference This parameter holds the switch’s call identification 


and point code values for a call. 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, the 
switches can perform for the call. This is true only 
if the Reorigination Type Location field in table 
OFCVAR is OPERINFO. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


Note 3: Depending on how the parameter is set up in table OFCVAR, the 
switch will look at either the Call Reference or Operator Information parameter 
to determine reorigination type. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 4-3 shows parameters in this 
FAR message that affect RLT functionality. 


Table 4-3 
RLT parameters in the FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 
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7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. Table 4-4 
shows parameters in the billing FAA message that affect RLT 
functionality. 


Table 4-4 
RLT parameters in the FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. The remote switch passes the FAR to the bridging 
switch. Because the trunk connecting the bridging switch to the switch 
from which it originally received the call does not support RLT 
functionality, it reads the message’s Facility Indicator and performs 
release link trunking. Using translations of the Called Party Number 
parameter, the bridging switch completes the second leg of the call. 
Table 4-5 shows parameters in this FAR message that affect RLT 
functionality. 
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Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to Chapter 5, 
“RLT call scenarios for ESP,” for a description of boomerang reorigination. 


Table 4-5 
Important RLT parameters in this Redirect FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


10 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 4-6 shows parameters in this 
FAA message that affect RLT functionality. 
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Table 4-6 
Important RLT parameters in this Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. 


11 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


12 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


13 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. 


Figure 4-2 is a comprehensive message flow diagram for the redirect and 
transfer scenario. 
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Figure 4-2 
Message flow for redirect and transfer scenario 
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—continued— 
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Figure 4-2 
Message flow for redirect and transfer scenario (continued) 


Services platform 


Bridging Remote 
switch switch 


Facility Indicator 
Called Party Number 
Calling Party Number 
Generic Digits 
Operator Information 


Facility Indicator 
Called Party Number 
Calling Party Number 
Generic Digits 
Operator Information 


Facility Indicator 
Call Reference 


Facility Indicator 
Call Reference 


Legend: Parameters 
Bold = Mandatory Regular = Optional 


Italics =Required for RLT functionality 


—continued— 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


4-12 Common RLT call scenarios 


Figure 4-2 
Message flow for redirect and transfer scenario (continued) 
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ESP redirect and transfer error scenario 


This section explains the message flow for the redirect and transfer scenario 
when, for whatever reason, a UCS DMS-250 switch cannot perform the 
action requested in the Facility Indicator parameter of a FAR message. In 
this case, the switch involved does not perform the action requested (such as 
release link trunking) and cannot complete the call. The switches must 
process the call using call treatment or other means. The error scenario is 
identical to the standard redirect and transfer scenario up to step 7. 


Message flow for redirect and transfer error scenario 


Figure 4-3 is a comprehensive message flow diagram for the redirect and 
transfer error scenario. It shows the sequence for the exchange of messages 
and parameters between the bridging UCS DMS-250 switch, the remote 
UCS DMS-250 switch, and the services platform. 


Specifically, the message exchange in this error scenario occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. The 
switches and services platform exchange messages just as in steps 1-6 in 
the standard redirect and transfer scenario. 


2 The bridging switch checks a FAR message from the services platform. 
It determines that the trunk that connects it to the switch from which it 
originally received the call is either a PTS trunk or an ISUP trunk that 
does not support RLT. This switch reads and tries to perform the action 
designated in the FAR message’s Facility Indicator parameter. In this 
scenario, for whatever reason, the switch is unable to perform the action. 


3 The switch that attempted bridging returns a Facility Reject (FRJ) 
message to the remote switch to indicate that it could not perform the 
facility request. This message’s Cause Indicator parameter explains why 
the switch could not fulfill the request. 


4 Ifthe value of the Cause Indicator parameter is Switching Equipment 
Congestion, the remote switch attempts to bridge the call. If the Cause 
Indicator has some other value, or the remote switch cannot bridge the 
call for some other reason, then the remote switch passes the FRJ 
message to the services platform. 


5 Until the call is completed, the services platform bridges the call and 
maintains connections on all of the trunks and switches that support both 
legs of the call. 
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Figure 4-3 
Message flow for redirect and transfer error scenario 
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Figure 4-3 
Message flow for redirect and transfer error scenario (continued) 
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Third-party interaction scenario 


In this scenario, a customer makes a call that requires the services platform 
to place the three-way call. When the parties are in conference, the services 
platform requests release link trunking. After the appropriate switch bridges 
the call, the release link trunking capability frees the services platform and 
the remote switch. 


The trunks connecting the bridging switch, the remote switch, and the 
services platform are all ISUP IMTs with RLT functionality. The trunk 
connecting the caller to the bridging switch is one of the following: 


e a PTS trunk 

e a PRI trunk 

e an ISUP FGD trunk 

e an ISUP IMT without RLT functionality 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 


Figure 4-4 is a high-level diagram of the third-party interaction scenario. 
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Figure 4-4 
Third-party interaction scenario 
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Message flow for third-party interaction 


Figure 4-5 is a comprehensive message flow diagram for the third-party 
interaction scenario. The diagram shows the sequence for the exchange of 


messages between the bridging switch, the remote switch, and the services 


platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the bridging switch in this scenario, receives a call. Based on 
the nature of the call, the bridging switch formats an IAM and sends it to 


another switch, the remote switch in this scenario. 


Note: If the call is an NOO services call, the switch performs NOO lookup 


(it translates the NOO services call into a ten-digit number). The switch 


places the NOO number into the CDR’s Dialed Number field and places 


the ten-digit number into the CDR’s Called Number field. 


2 In response to the IAM from the bridging switch, the remote switch 


sends another IAM to the services platform. Table 4-7 provides a list of 


parameters in the IAM that affect RLT functionality. 


Table 4-7 


RLT parameters in a first leg IAM 


RLT parameter 


Called Party Number 


Charge Number 


Comments 


The UCS DMS-—250 switches use the number of 
the party called when generating billing records. 
The switches place this value in the Called 
Number field of the CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


—continued— 
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Table 4-7 
RLT parameters in a first leg IAM (continued) 
RLT parameter Comments 
Calling Party Number This parameter contains an ANI value. The 


switches add this ANI value to the ANI SPILL field 
in the call’s CDR, unless they pull the ANI value 
from the Charge Number parameter. 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


—end— 


3 The services platform returns an ACM to the remote switch. The ACM 
confirms that the services platform received the information needed to 
route the call to its destination. The remote switch passes the ACM to the 
bridging switch. 


4 When the services platform answers the call, the platform sends an ANM 
to the remote switch. The remote switch formats and sends another 
ANM to the bridging switch. Table 4-8 shows parameters in this ANM 
that affect RLT functionality. 
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Table 4-8 
Important RLT parameters in this ANM 
RLT parameter Comments 
Operator Information This parameter provides operator information to 


the bridging switch which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields of the OSR for the call. 


This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party and initiates the second 
leg of the call, formatting a new IAM and sending it to the remote 
switch. Because the trunk connecting the remote switch and the services 
platform supports RLT functionality, the IAM includes the 
Supplementary Line Information (SLI) parameter. 


6 When it receives the IAM, the remote switch formats another IAM and 
sends it to the bridging switch. Because the trunk connecting the remote 
switch and the bridging switch supports RLT functionality, this IAM also 
includes the SLI parameter. Table 4-9 shows parameters in this IAM that 
affect RLT functionality. 
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Table 4-9 
Important RLT parameters in this second leg IAM 
RLT parameter Comments 
Called Party Number The switches use the number of the party called 


when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


Calling Party Number This parameter contains an ANI value. The 
switches add this ANI value to the ANI SPILL field 
in the call’s CDR, unless they pull the ANI value 
from the Charge Number parameter. 


Charge Number This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


Supplementary Line This parameter causes a receiving switch to 

Information (SLI) include a Call Reference parameter in an ACM 
when it responds. In this scenario, this parameter 
has an RLT Call Operation value. 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLTO002). 
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7 


In response to the IAM with the SLI parameter, the bridging switch 
returns an ACM with a Call Reference parameter that identifies the 
second leg of the call. This ACM indicates that the terminating switch 
received the information that it needs to route the call. 


The remote switch copies and saves the Call Reference parameter from 
the ACM. As each intermediate tandem switch passes this ACM, it 
replaces its own call identification and point code values with the values 
in this parameter. The switch routes this ACM to the services platform, 
which also saves the Call Reference parameter. Table 4-10 shows 
parameters in this ACM that affect RLT functionality. 


Table 4-10 
Important RLT parameters in this second leg ACM 


RLT parameter Comments 


Call Reference This parameter holds the switch’s call identification 


and point code values for a call. The switches 
pass this information backward in a FAR message 
to the bridging switch to allow it to bridge the 
correct two calls. 


10 


11 


When the terminating party of the second leg answers, the bridging 
switch formats an ANM and sends it to the remote switch. The remote 
switch passes the ANM to the services platform, connecting it in a 
three-way call with the calling party and called party. 


The services platform initiates billing by sending a FAR message to the 
remote switch. 


The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. Table 4-11 shows parameters in this FAR message 
that affect RLT functionality. 


Table 4-11 
Important RLT parameters in this Billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 


uses. 
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12 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: If the trunk between the bridging switch and the remote switch 
in the scenario in Note 1 did not support release link trunking, the remote 
switch would not pass the FAR message, and would therefore be the 
bridging switch. 


13 To acknowledge that it received and processed the FAR message, the 
bridging switch formats an FAA message and sends it to the remote 
switch, which passes it to the services platform. Table 4-12 shows 
parameters in this FAA message that affect RLT functionality. 


Table 4-12 
Important RLT parameters in this billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the same Start 
Billing Time value that was in the FAR message. 


14 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. 


Note: A services platform always sends a FAR message to the trunk 
circuit of the leg for which it does not have Call Reference information. 
In this scenario, the services platform sends the FAR message to the 
trunk of the call’s first leg. 
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15 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


16 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch (see step 8). The remote switch adds this Call 
Reference information to a FAR message and sends the message to the 
bridging switch. Table 4-13 shows parameters in this FAR message that 
affect RLT functionality. 


Table 4-13 
Important RLT parameters in this third-party FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the action that the FAR 
message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem switch 
passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


—continued— 
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Table 4-13 
Important RLT parameters in this third-party FAR message 
RLT parameter Comments 
Generic Digits This parameter contains the CALLID value that the 


services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


—end— 


17 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 


18 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 4-14 shows parameters in this 
FAA message that affect RLT functionality. 


Table 4-14 
Important RLT parameters in this third-party FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
UCS DMS-250 switch. In this scenario, this 
parameter contains the Release Link for 3'4 Party 
Interaction Call value that was in the FAR 
message. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


19 After bridging the call, the bridging switch formats two REL messages 
and sends them to the remote switch to release the call connections for 
both call legs. The REL messages include Normal Clearing Cause 
Indicator parameters. 
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20 The remote switch sends two REL messages to the services platform and 
releases the call connections to the services platform and the 
corresponding trunks. It also sends two RLC messages back to the 
bridging switch to confirm the release of the first and second call legs. 
The RLC’s also include proper Cause Indicator parameters. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


21 The services platform also releases its connections and returns two 
RLC’s with proper Cause Indicator parameters to the remote switch to 
confirm the release of both call legs. 


Figure 4-5 is a comprehensive message flow diagram for the third-party 
interaction scenario. 
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Figure 4-5 
Message flow for third-party interaction scenario 
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Figure 4-5 
Message flow for third-party interaction scenario (continued) 
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Figure 4-5 
Message flow for third-party interaction scenario (continued) 
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Figure 4-5 
Message flow for third-party interaction (continued) 
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Third-party interaction error scenario 


This section explains the message flow for the third-party interaction 
scenario when, for whatever reason, a UCS DMS-250 switch or 
interconnecting trunk cannot perform the action requested in the Facility 
Indicator parameter of a FAR message. In this case, the switch involved does 
not perform the action requested (such as release link trunking), but may 
complete the call, depending on conditions. The error scenario is identical to 
the standard third-party interaction scenario up to step 16. 


Message flow for third-party interaction error scenario 


Figure 4-6 is a comprehensive message flow diagram for the third-party 
interaction error scenario. It shows the sequence for the exchange of 
messages and parameters between the bridging switch, the remote switch, 
and the services platform. 


Specifically, the message exchange in this error scenario occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. The 
switches and services platform exchange messages just as in steps 1-16 
in the standard third-party interaction scenario 


2 The bridging switch checks a FAR message from the services platform. 
It determines that the trunk that connects it to the switch from which it 
originally received the call is either a PTS trunk or an ISUP trunk that 
does not support RLT. This switch reads and tries to perform the action 
designated in the FAR message’s Facility Indicator parameter. In this 
scenario, for whatever reason, the switch is unable to perform the action. 


3 The switch that attempted bridging returns an FRJ message to the remote 
switch to indicate that it could not perform the facility request. This 
message’s Cause Indicator parameter explains why the switch could not 
fulfill the request. 


4 Ifthe value of the Cause Indicator parameter is Switching Equipment 
Congestion, the remote switch attempts to bridge the call. If the Cause 
Indicator has some other value, or the remote switch cannot bridge the 
call for some other reason, then the remote switch passes the FRJ 
message to the services platform. 


5 Until the call is completed, the services platform bridges the call and 
maintains connections on all of the trunks and switches that support both 
legs of the call. 
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Figure 4-6 


Message flow for third-party interaction error scenario 
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Figure 4-6 
Message flow for third-party interaction error scenario (continued) 
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Figure 4-6 
Message flow for third-party interaction error scenario (continued) 
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Services platform-initiated callback scenario 


In this scenario, the services platform disconnects a call for any of several 
reasons, such as when the terminator is not available until later, without 
connecting it to the terminator. Later, the services platform initiates a call to 
the first call’s terminator, then initiates a second call to the first call’s 
originator, and requests release link trunking. After the appropriate switch 
bridges the call, the release link trunking capability frees the services 
platform and the remote switch. 


The trunks connecting the bridging switch, the remote switch, and the 
services platform are all ISUP IMTs with RLT functionality. The trunk 
connecting the caller to the bridging switch is one of the following: 


a PTS trunk 

a PRI trunk 

an ISUP FGD trunk 

an ISUP IMT without RLT functionality 
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By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 


Figure 4-7 is a high-level diagram of the services platform-initiated callback 
scenario. 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


4-36 Common RLT call scenarios 


Figure 4-7 
Services platform-initiated callback scenario 
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Message flow for ESP-initiated callback scenario 


Figure 4-8 is a comprehensive message flow diagram for the services 
platform-initiated callback scenario. It shows the sequence for the exchange 
of messages and parameters between the bridging switch, the remote switch, 
and the services platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. Based on 
the nature of the call, the bridging switch formats an IAM and sends it to 
another switch, the remote switch in this scenario. 


Note: If the call is an NOO services call, the switch performs NOO lookup 
(that is, it translates the NOO services call into a ten-digit number). The 
switch places the NOO number in the CDR’s Dialed Number field and 
places the ten-digit number in the CDR’s Called Number field. 


2 In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 4-15 shows 
parameters in this IAM that affect RLT functionality. 


Table 4-15 
Important RLT parameters in this IAM 


RLT parameter Comments 


Called Party Number The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


Calling Party Number This parameter contains an ANI value. The 
switches add this value to the ANI SPILL field in 
the call’s CDR, unless they pull the ANI value from 
the Charge Number parameter. 


—continued— 
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Table 4-15 
Important RLT parameters in this IAM (continued) 
RLT parameter Comments 
Charge Number This parameter contains an ANI value. If the IAM 


contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


—end— 


3 The services platform returns an ACM to the remote switch. The ACM 
confirms that the services platform received the information needed to 
route the call to its destination. The remote switch passes the ACM to the 
bridging switch. 


4 When the services platform answers the call, the platform sends an ANM 
to the remote switch. The remote switch formats and sends another 
ANM to the bridging switch. Table 4-16 shows parameters in this ANM 
that affect RLT functionality. 
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Table 4-16 
Important RLT parameters in this ANM 
RLT parameter Comments 
Operator Information This parameter provides operator information to 


the bridging switch which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields of the OSR for the call. 


This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party from the IAM, but does 
not make the call to that party. The services platform informs the calling 
party that they will be called back later when the services platform can 
complete a call to the call’s terminator. The services platform then 
disconnects the call. 


6 Later, the services platform initiates a call to the original call’s called 
party, formatting a new IAM and sending it to the remote switch. 
Because the trunk connecting the remote switch and the services 
platform supports RLT functionality, and is a call-back call, the [AM 
includes the SLI parameter. Table 4-17 shows parameters in this IAM 
that affect RLT functionality. 
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Table 4-17 
Important RLT parameters in this second leg IAM 
RLT parameter Comments 
Called Party Number The switches use the number of the party called 


when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


Calling Party Number This parameter contains an ANI value. The 
switches add this value to the ANI SPILL field in 
the call’s CDR, unleashed ANI value from the 
Charge Number parameter is used. 


Charge Number This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


Supplementary Line This parameter causes a receiving switch to 

Information (SLI) include a Call Reference parameter in an ACM 
when it responds. In this scenario, this parameter 
has an RLT Call-back call value. 


7 When it receives the IAM, the remote switch formats another IAM and 


sends it to the bridging switch. Because the trunk connecting the remote 
switch and the bridging switch supports RLT functionality, this [AM also 
includes the SLI parameter. 


In response to the IAM with the SLI parameter, the bridging switch 
returns an ACM with a Call Reference parameter that identifies the 
original call. This ACM indicates that the terminating switch received 
the information that it needs to route the call. 


The remote switch copies and saves the Call Reference parameter from 
the ACM. Then it changes the Call Reference in the ACM to contain the 
Call Reference information for the first leg of the callback. The switch 
routes this ACM to the services platform, which also saves the Call 
Reference parameter. Table 4-18 shows parameters in this ACM that 
affect RLT functionality. 
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Table 4-18 
Important RLT parameters in this second leg ACM 


RLT parameter Comments 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. 


Note: As each intermediate tandem switch 
passes this ACM, it replaces its own call 
identification and point code values with the values 
in this parameter. 


10 When the terminating party of the first leg answers, the bridging switch 
formats an ANM and sends it to the remote switch. The remote switch 
passes the ANM to the services platform. 


11 The services platform initiates the call’s first leg by making a call to the 
initial call’s originator. The services platform formats a new IAM and 
sends it to the remote switch. Because the trunk connecting the remote 
switch and the services platform supports RLT functionality, and this is a 
call-back call, the IAM includes the SLI parameter with an RLT callback 
indicator. Table 4-19 shows parameters in this IAM that affect RLT 
functionality. 
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Table 4-19 
Important RLT parameters in this first leg IAM 
RLT parameter Comments 
Calling Party Number This parameter contains an ANI value. The 


switches add this value to the ANI SPILL field in 
the call’s CDR, unless they pull the ANI value from 
the Charge Number parameter. 


Called Party Number The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


Charge Number This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


Supplementary Line This parameter identifies the call as being initiated 
Information by the services platform. In this scenario, this 
parameter has an RLT Call Back Call value. 


12 When it receives the IAM, the remote switch formats another IAM and 
sends it to the bridging switch. Because the trunk connecting the remote 
switch and the bridging switch supports RLT functionality, and it is a 
call-back call, this IAM also includes the SLI parameter. 


13 In response to the IAM with the SLI parameter, the bridging switch 
returns an ACM that the terminating switch received the information that 
it needs to route the call. The remote switch passes the ACM to the 
services platform. 


14 When the terminating party of the first leg answers, the bridging switch 
formats an ANM and sends it to the remote switch. The remote switch 
passes the ANM to the services platform, connecting it in a three-way 
call with the calling party and called party. 


15 The services platform initiates billing by sending a FAR message to the 
remote switch. Table 4-20 shows parameters in this FAR message that 
affect RLT functionality. 
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Table 4-20 
Important RLT parameters in this Billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


16 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


17 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch to which it 
originally terminated the call supports RLT functionality. If so, it passes 
the FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


18 To acknowledge that it received and processed the FAR message, the 
bridging switch formats an FAA message and sends it to the remote 
switch, which passes it to the services platform. Table 4-21 shows 
parameters in this FAA message that affect RLT functionality. 
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Table 4-21 


Important RLT parameters in this Billing FAA message 


RLT parameter 


Facility Indicator 


Comments 


This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the same Start 
Billing Time value that was in the FAR message. 


19 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. Table 4-22 shows parameters in this FAR message 
that affect RLT functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have call reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 


Table 4-22 


Important RLT parameters in this FAR message 


RLT parameter 


Comments 


Facility Indicator 


Call Reference 


Called Party Number 


This parameter defines the action that the FAR 
message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem switch 
passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


—continued— 
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Table 4-22 
Important RLT parameters in this FAR message (continued) 


RLT parameter Comments 


Calling Party Number The switches, except billing switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


—end— 


20 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


21 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch (see step 8). The remote switch adds this 
reference information to a FAR message and sends the message to the 
bridging switch. 


22 The bridging switch reads the message’s Facility Indicator parameter and 
bridges the terminating trunk of the first call leg to the terminating trunk 
of the second call leg. The bridging switch uses the information in the 
FAR message’s Call Reference parameter to identify the second leg. 


23 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 4-23 shows parameters in this 
FAA message that affect RLT functionality. 
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Table 4-23 
Important RLT parameters in this FAA message 


RLT parameter Comments 


Facility indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for 3'¢ Party Interaction Call value that was in 
the FAR message. 


24 After bridging the call, the bridging switch formats two REL messages 
and sends them to the remote switch to release the call connections for 
both call legs. The REL messages include proper Cause Indicator 
parameters. 


25 The remote switch sends two REL messages to the services platform and 
releases the call connections to the services platform and the 
corresponding trunks. It also sends two RLC messages back to the 
bridging switch to confirm the release of the first and second call legs. 
The RLC’s also include proper Cause Indicator parameters. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


26 The services platform also releases its connections and returns two 
RLC’s with proper Cause Indicator parameters to the remote switch to 
confirm the release of both call legs. 


Figure 4-8 is a comprehensive message flow diagram for the services 
platform-initiated callback scenario. 
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Figure 4-8 
Message flow for services platform-initiated callback scenario 
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Figure 4-8 
Message flow for services platform-initiated callback scenario (continued) 
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Figure 4-8 
Message flow for services platform-initiated callback scenario (continued) 
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Figure 4-8 
Message flow for services platform-initiated callback scenario (continued) 
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Figure 4-8 
Message flow for services platform-initiated callback scenario (continued) 
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Reorigination scenario with bridging at originating switch 


In this scenario, the services platform transfers the call to its destination and 
requests release link trunking. After the appropriate switch bridges the call, 
the release link trunking capability frees the services platform and the 
remote switch. 


The trunks connecting the bridging switch, the remote switch, and each 
services platform is an ISUP intermachine trunk (IMT) with RLT 
functionality. The trunk connecting the caller to the bridging switch is one of 
the following: 


e aper-trunk signaling (PTS) trunk 
e an ISUP FGD trunk 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 
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Figure 4-9 is a high-level diagram of the reorigination scenario with 
bridging at an originating switch. 


Figure 4-9 
Reorigination scenario with bridging at originating switch 
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Message flow for reorigination scenario 


Figure 4-10 is a comprehensive message flow diagram for the reorigination 
scenario. It shows the sequence for the exchange of messages and 
parameters between the bridging switch, the remote switch, and the services 
platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. Based on 
the nature of the call, the bridging switch formats an Initial Address 
Message (IAM) and sends it to another switch, the remote switch in this 
scenario. 


Note: If the call is an NOO services (700, 800, or 900) call, the switch 
performs N00 lookup (that is, it translates the NOO services call into a 
ten-digit number). The switch places the NOO number in the CDR’s 
Dialed Number field and places the ten-digit number into the CDR’s 
Called Number field. 


2 In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 4-24 shows 
parameters in this IAM that affect RLT functionality. 


Table 4-24 
Important RLT parameters in this IAM 


RLT parameter Comments 


Called Party Number The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides a Nature of Address 
(NOA) value that indicates whether the call is 
operator-assisted or whether the switch must treat 
the call. 


Charge Number This parameter contains an automatic numbering 
identification (ANI) value. If the IAM contains this 
parameter, the switches add this value to the ANI 
SPILL field in the call’s CDR. If the IAM does not 
contain this parameter, the switches get the ANI 
value from the Calling Party Number parameter. 


—continued— 
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Table 4-24 
Important RLT parameters in this IAM 
RLT parameter Commenis 
Calling Party Number This parameter contains an ANI value. The 


switches add this value to the ANI SPILL field in 
the call’s CDR, unless they pull the ANI value from 
the Charge Number parameter. 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


—end— 


3 The services platform returns an Address Complete Message (ACM) to 
the remote switch. The ACM confirms that the services platform 
received the information needed to route the call to its destination. The 
remote switch passes the ACM to the bridging switch. 


4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. Table 4-25 
shows parameters in this ANM that affect RLT functionality. 


Table 4-25 
Important RLT parameters in this ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 
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5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 4-26 shows parameters in 
this FAR message that affect RLT functionality. 


Table 4-26 
Important RLT parameters in this billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. Table 4-27 
shows parameters in this FAA message that affect RLT functionality. 
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Table 4-27 
Important RLT parameters in this Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The services platform then sends a Facility Request (FAR) message to 
the remote switch. Table 4-28 shows parameters in this FAR message 
that affect RLT functionality. 


Table 4-28 
Important RLT parameters in this reorigination FAR message 


RLT parameter Comments 


Operator Information This parameter contains reorigination information 
in the Reorigination Type field. 


10 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


11 The bridging switch also checks the FAR message. This switch reads and 
performs the action designated in the FAR message’s Operator 
Information parameter. In this case, the switch deallocates all the 
reorigination resources (if any) and then allocates new resources as 
designated in the FAR. 


Note: The services platform may send a reorigination FAR several 
times. 


12 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. 


13 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. Table 4-29 shows parameters in this FAR message 
that affect RLT functionality. 
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Table 4-29 
Important RLT parameters in this Redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


This parameter also contains the Reorigination 
Type field, and may contain the following other 
reorigination fields: Bridge Reorigination Control, 
UTR Digit, Reorigination Trigger Type, 
Reorigination Allowed, STR Digit, STR Key 
Duration at Talking, STR Key Duration at 
Non-Talking, Immediate, and Disconnect Timer. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


14 The remote switch passes the FAR to the bridging switch. In this case, 
the deallocates all the reorigination resources (if any) and then allocates 
new resources as designated in the Operator Information parameter of 
the FAR. 
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15 Because the trunk connecting the bridging switch to the switch from 
which it originally received the call does not support RLT functionality, 
the bridging switch reads the message’s Facility Indicator and performs 
release link trunking. Using translations of the Called Party Number 
parameter, the bridging switch completes the second leg of the call. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to 

Chapter 5, “RLT call scenarios for ESP,” for a description of boomerang 
reorigination. 


16 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 4-30 shows parameters in this 
FAA message that affect RLT functionality. 


Table 4-30 
Important RLT parameters in this Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the “Release 
Link for Operator Redirect/Transfer” value that was 
in the FAR message. 


17 The services platform then sends a Facility Request (FAR) message to 
the remote switch. Table 4-31 shows parameters in this FAR message 
that affect RLT functionality. 


Table 4-31 
Important RLT parameters in this reorigination FAR message 


RLT parameter Comments 


Operator Information This parameter contains reorigination information 


in the Reorigination Type field. 


18 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 
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19 


20 


21 


22 


23 


The bridging switch also checks the FAR message. This switch reads and 
performs the action designated in the FAR message’s Operator 
Information parameter. In this case, the deallocates all the reorigination 
resources (if any) and then allocates new resources as designated in the 
FAR. 


Note: The services platform may send a reorigination FAR several 
times. 


To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. 


After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. 


Figure 4-10 is a comprehensive message flow diagram for the reorigination 
scenario. 
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Figure 4-10 
Message flow for reorigination scenario 
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Figure 4-10 
Message flow for reorigination scenario (continued) 
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Figure 4-10 
Message flow for reorigination scenario (continued) 
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Reorigination error scenario with bridging at originating switch 


This section explains the message flow for the reorigination scenario when, 
for whatever reason, a UCS DMS-250 switch cannot perform the action 
requested in the Facility Indicator parameter of a FAR message. In this case, 
the switch involved does not perform the action requested (such as release 
link trunking) and cannot complete the call. The switches must process the 
call using call treatment or other means. The error scenario is identical to the 
standard reorigination scenario up to step 13. 


Message flow for reorigination error scenario 


Figure 4-11 is a comprehensive message flow diagram for the reorigination 
error scenario. It shows the sequence for the exchange of messages and 
parameters between the bridging switch, the remote switch, and the services 
platform. 


Specifically, the message exchange in this error scenario occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. The 
switches and services platform exchange messages just as in steps 1-13 
in the standard reorigination scenario. 


2 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. Table 4-32 shows parameters in this FAR message 
that affect RLT functionality. 


Table 4-32 
Important RLT parameters in this Redirect FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


This parameter also contains the Reorigination 
Type field, and may contain the following other 
reorigination fields: 


—continued— 
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Table 4-32 

Important RLT parameters in this Redirect FAR message (continued) 
RLT parameter Comments 
Operator Information Bridge Reorigination Control, UTR Digit, 
(continued) Reorigination Trigger Type, Reorigination Allowed, 


STR Digit, STR Key Duration at Talking, STR Key 
Duration at Non-talking, Immediate, and 
Disconnect Timer. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


—end— 


3 The remote switch passes the FAR to the bridging switch. In this case, 
the attempts to deallocate all the reorigination resources (if any) and then 
allocate new resources as designated in the Operator Information 
parameter of the FAR. In this scenario, this reallocation fails. 


4 The bridging switch checks the Bridge Reorig. Control field in the 
Operator Information parameter of the FAR. If the field is N, the services 
attempts to redirect at the Bridging switch, regardless of the failure of 
resource allocation. If the field is Y, the services platform does not 
attempt to bridge. In this scenario, the Bridge Reorig. Control field is Y. 


5 The bridging switch sends an FRJ message to the remote switch 
containing the Cause Value Bridging failed due to reorigination failure. 
in the Cause Indicator parameter. Table 4-33 shows parameters in this 
FRJ message that affect RLT functionality. 
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Table 4-33 
Important RLT parameters in this FRJ message 
RLT parameter Comments 
Cause Indicator This parameter contains the value “Bridging failed 
due to reorigination failure” in the Cause Value 
field. 


The remote switch passes the FRJ message back to the services platform. 


The services platform then sends a Facility Request (FAR) message to 
the remote switch. Table 4-34 shows parameters in this FAR message 
that affect RLT functionality. 


Table 4-34 
Important RLT parameters in this reorigination FAR message 


RLT parameter Comments 


Operator Information This parameter contains reorigination information 
in the Reorigination Type field. 


8 The remote switch checks the FAR message and passes it to the bridging 
switch. 


9 The bridging switch also checks the FAR message. This switch reads and 
performs the action designated in the FAR message’s Operator 
Information parameter. In this case, the switch deallocates all the 
reorigination resources (if any) and then allocates new resources as 
designated in the FAR. 


Note: The services platform may send a reorigination FAR several 
times. 


10 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. 


11 Until the call is completed, the services platform bridges the call and 
maintains connections on all of the trunks and switches that support both 
legs of the call. 


Figure 4-11 is a comprehensive message flow diagram for the reorigination 
error scenario. 
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Figure 4-11 
Message flow for reorigination scenario 
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Figure 4-11 


Message flow for reorigination scenario (continued) 
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Figure 4-11 
Message flow for reorigination scenario (continued) 
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Reorigination scenario, bridging not at originating or services 


platform 


In this scenario, the ESP transfers the call to its destination and requests 
release link trunking. After the appropriate switch bridges the call, the 
release link trunking capability frees the services platform and the remote 
switch. 


The trunks connecting the bridging switch, the remote switch, and each 
services platform is an ISUP intermachine trunk (IMT) with RLT 
functionality. The trunk connecting the caller to the bridging switch is one of 
the following: 


e per-trunk signaling (PTS) trunk 
e ISUP FGD trunk 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 


Figure 4-12 is a high-level diagram of the reorigination scenario. 
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Figure 4-12 
Reorigination scenario 
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Message flow for reorigination scenario 


Figure 4-13 is a comprehensive message flow diagram for the reorigination 
scenario where bridging occurs at a switch other than the originating or 
services platform. It shows the sequence for the exchange of messages and 
parameters between the bridging switch, the remote switch, and the services 


platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the originating switch in this scenario, receives the call. Based 
on the nature of the call, the originating switch formats an Initial 
Address Message (IAM) and sends it to another switch, the bridging 


switch in this scenario. 


2 In response to the IAM from the originating switch, the bridging switch 
sends another IAM to the services platform. Table 4-35 shows 
parameters in this IAM that affect RLT functionality. 


Table 4-35 
RLT parameters in the IAM 


Heading 


Heading 


Called Party Number 


Charge Number 


The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides a Nature of Address 
(NOA) value that indicates whether the call is 
operator-assisted or whether the switch must treat 
the call. 


This parameter contains an automatic numbering 
identification (ANI) value. If the IAM contains this 
parameter, the switches add this value to the ANI 
SPILL field in the call’s CDR. If the IAM does not 
contain this parameter, the switches get the ANI 
value from the Calling Party Number parameter. 


—continued— 
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Table 4-35 
RLT parameters in the IAM 


Heading 


Calling Party Number 


Transit Network Selector 


Heading 


This parameter contains an ANI value. The 
switches add this value to the ANI SPILL field in 
the call’s CDR, unless they pull the ANI value from 
the Charge Number parameter. 


This parameter’s Reorigination Call field identifies 
whether the call is a boomerang reorigination call 
(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


—end— 


3 The services platform returns an Address Complete Message (ACM) 
to the bridging switch. The ACM confirms that the services platform 
received the information needed to route the call to its destination. 
The bridging switch passes the ACM to the originating switch. 


4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the bridging switch. The bridging switch 
formats and sends another ANM to the originating switch. Table 4-36 
shows parameters in this ANM that affect RLT functionality. 


Table 4-36 


Important RLT parameters in this ANM 


RLT parameter 


Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 
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5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the bridging switch. Table 4-37 shows parameters in 
this FAR message that affect RLT functionality. 


Table 4-37 
Important RLT parameters in this billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The bridging switch checks the FAR message and determines that the 
trunk connecting the originating switch and the bridging supports RLT 
functionality. The bridging switch passes this FAR to the Originating 
switch. This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, bridging, and originating 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the originating switch 
and the bridging switch in this scenario did not support release link 
trunking, the bridging switch would not pass the FAR message, and 
would therefore be the bridging switch. 


7 To acknowledge that it received and processed the FAR message, the 
originating switch formats a Facility Accept (FAA) message and sends it 
to the bridging switch, which passes it to the services platform. 

Table 4-38 shows parameters in this FAA message that affect RLT 
functionality. 
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Table 4-38 
Important RLT parameters in this Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the same Start 
Billing Time value that was in the FAR message. 


8 The services platform then sends a Facility Request (FAR) message to 
the bridging switch. Table 4-39 shows parameters in this FAR message 
that affect RLT functionality. 


Table 4-39 
Important RLT parameters in this reorigination FAR message 


RLT parameter Comments 


Operator Information This parameter contains reorigination information 
in the Reorigination Type field. 


9 The bridging switch checks the FAR message and determines that the 
trunk connecting the originating switch and the bridging switch supports 
RLT functionality. The bridging switch then passes the FAR message to 
the originating switch. 


10 The originating switch also checks the FAR message. This switch reads 
and performs the action designated in the FAR message’s Operator 
Information parameter. In this case, the UCS DMS—250 deallocates all 
the reorigination resources (if any) and then allocates new resources as 
designated in the FAR. 


Note: The services platform may send a reorigination FAR several 
times. 


11 To acknowledge that it received and processed the FAR message, the 
originating switch formats a Facility Accept (FAA) message and sends it 
to the bridging switch, which passes it to the services platform. 


12 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. Table 4-40 shows parameters in this FAR message 
that affect RLT functionality. 
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Table 4-40 
Important RLT parameters in this Redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


This parameter also contains the Reorigination 
Type field, and may contain the following other 
reorigination fields: Bridge Reorigination Control, 
UTR Digit, Reorigination Trigger Type, 
Reorigination Allowed, STR Digit, STR Key 
Duration at Talking, STR Key Duration at 
Non-talking, Immediate, and Disconnect Timer. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


13 The bridging switch copies the FAR to another FAR, changing the 
Facility Indicator field that contains the Reorigination value. The 
bridging switch passes the FAR to the originating switch. In this case, 
the originating switch deallocates all the reorigination resources (if any) 
and then allocates new resources as designated in the Operator 
Information parameter of the FAR. 
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14 Using translations of the Called Party Number parameter, the bridging 
switch completes the second leg of the call. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to 

Chapter 5, “RLT call scenarios for ESP,” for a description of boomerang 
reorigination. 


15 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the service platform. The 
services platform then reads the message’s Facility Indicator and 
performs release link trunking. Table 4-41 shows parameters in this FAA 
message that affect RLT functionality. 


Table 4-41 
Important RLT parameters in this Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


16 The services platform then sends a Facility Request (FAR) message to 
the bridging switch. Table 4-42 shows parameters in this FAR message 
that affect RLT functionality. 


Table 4-42 
Important RLT parameters in this reorigination FAR message 
RLT parameter Comments 
Operator Information This parameter contains reorigination information 


in the Reorigination Type field. 


17 The bridging switch checks the FAR message. This switch reads and 
performs the action designated in the FAR message’s Operator 
Information parameter. In this case, the switch deallocates the 
reorigination resources and allocates new resources. 


Note: The services platform may send a reorigination FAR several 
times. 
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18 


19 


20 


21 


To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. 


After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the originating switch. The REL message 
includes a Normal Clearing Cause Indicator parameter. 


The bridging switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the bridging switch to confirm the 
release. 


Figure 4-13 is a comprehensive message flow diagram for the reorigination 
scenario where bridging occurs at a switch other than the originating or 
services platform. 
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Figure 4-13 
Message flow for reorigination scenario 
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Figure 4-13 
Message flow for reorigination scenario (continued) 
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Figure 4-13 
Message flow for reorigination scenario (continued) 
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Reorigination error scenario, 
bridging not at originating or services platform 


This section explains the message flow for this reorigination scenario, where 
the call bridging occurs at a switch other than the originating or services 
platform and, for whatever reason, a UCS DMS-250 switch cannot perform 
the action requested in the Facility Indicator parameter of a FAR message. In 
this case, the switch involved does not perform the action requested (such as 
release link trunking) and cannot complete the call. The switches must 
process the call using call treatment or other means. The error scenario is 
identical to the standard reorigination scenario up to step 13. 


Message flow for reorigination error scenario 
Figure 4-14 is a comprehensive message flow diagram for the reorigination 
error scenario when bridging occurs at a switch other than the originating or 
services platform. It shows the sequence for the exchange of messages and 
parameters between the originating switch, the bridging switch, and the 
services platform. 


Specifically, the message exchange in this error scenario occurs as follows: 


1 A switch, the originating switch in this scenario, receives the call. The 
switches and services platform exchange messages just as in steps 1-13 
in the standard reorigination scenario. 


2 The services platform then sends a Facility Request (FAR) message to 
the bridging switch. 


3 The bridging switch also checks the FAR message. This switch reads and 
performs the action designated in the FAR message’s Operator 
Information parameter. In this case, the switch is unable to deallocate the 
reorigination resources and allocate new resources. 


Note: The services platform may send a reorigination FAR several times. 


4 The services platform initiates release link trunking, sending another 
FAR message to the bridging switch. Table 4-43 shows parameters in 
this FAR message that affect RLT functionality. 
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Table 4-43 
Important RLT parameters in this Redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


This parameter also contains the Reorigination 
Type field, and may contain the following other 
reorigination fields: Bridge Reorigination Control, 
UTR Digit, Reorigination Trigger Type, 
Reorigination Allowed, STR Digit, STR Key 
Duration at Talking, STR Key Duration at 
Non-talking, Immediate, and Disconnect Timer. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 


5 The bridging switch checks the Bridge Reorigination Control field in the 
Operator Information parameter of the FAR. If the field is N, the services 
platform attempts to redirect at the Bridging switch, regardless of the 
failure of resource allocation. If the field is Y, the services platform does 
not attempt to bridge. In this scenario, the Bridge Reorig. Control field is 
Y. 
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6 The bridging switch sends an FRJ message to the services platform 
containing the Cause Value Resource unavailable - unspecified in the 
Cause Indicator parameter. Table 4-44 shows parameters in this FRJ 
message that affect RLT functionality. 


Table 4-44 
Important RLT parameters in this FRJ message 


RLT parameter Comments 


Cause Indicator This parameter contains the value Resource 
unavailable - unspecified in the Cause Value field. 
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Figure 4-14 
Message flow for reorigination scenario 
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Figure 4-14 


Message flow for reorigination scenario (continued) 
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Figure 4-14 
Message flow for reorigination scenario (continued) 


ba ge a Services platform 
Originating Bridging 


switch switch 


Facility Indicator 
Operator Information 


FRJ 


Facility Indicator 
Call Reference 


Legend: Parameters 
Bold = Mandatory Regular = Optional 


Italics =Required for RLT functionality 


—end— 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


5-1 


RLT call scenarios for ESP 


This chapter summarizes the flow of SS7 Integrated Services Digital 
Network (ISDN) User Part (SUP) messages between a bridging UCS 
DMS-250 switch, a remote UCS DMS-250 switch, and an Enhanced 
Services Provider (ESP) platform. It provides a high-level diagram and a 
general description for each of the ESP Release Link Trunk (RLT) call 
scenarios. 


An ESP platform is a generic reference to a company that provides 
specialized switching, billing, and call processing using a software system or 
systems. An ESP platform can provide enhanced services like calling card, 
debit card, and voice mail. 


For technical descriptions of messages and parameters that the UCS 
DMS-250 switches exchange in these scenarios, see Chapter 3, “SS7 ISUP 
RLT messages and protocol.” 


Note: The remote switch shown in the diagrams can also be the bridging 
switch under the proper conditions. For clarity, however, the bridging and 
remote switches in this chapter’s explanations are not the same switch. Even 
when the remote switch is the bridging switch, each scenario remains 
essentially the same. 


The scenarios do not explain how a UCS DMS-250 switch generates billing 
records for each RLT call. For billing information, see Chapter 7, “Billing 
for RLT calls.” 

The following are the RLT call scenarios that specifically involve an ESP: 

e boomerang reorigination 


e multiple Answer Messages (ANM) 
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Boomerang reorigination scenario 


In this scenario, a customer presses the octothorpe (#) key to request 
reorigination and the switching network routes the reoriginated call back to 
an ESP. For boomerang reorigination, the UCS DMS-250 switches use the 
original dialed number to reoriginate the call. After the appropriate switch 
bridges the call, the release link trunking capability frees the ESP and the 
remote switch. 


Enhancements to this feature including the following functionality: 


A services platform can send a new FAR (Facility Request) message 
(Context_Block FAR) containing up to a 100 byte block of context 
information (Context Block). 


After boomerang reorigination, an Initial Address Message (IAM) sent 
back to the services platform indicates whether the UCS DMS-250 
switch has the context block sent previously in the Context_Block FAR. 
This message also includes information about the state of the call 
(connecting, talking, or disconnecting) at the time of reorigination. 


The services platform retrieves the context block by sending the new 
FAR, Request_Context_Block. 


The UCS DMS-250 switch, upon receiving the new Request_Block 
FAR, sends the context block back in an FAA (Facility Accept) message. 


Limitations and restrictions 


The feature is supported by ESP only. 


All switches in the network must have the UCS08 or higher software 
load in order to make use of the context block functionality. Otherwise, 
the call context block is lost because no explicit messaging is supported 
to inform the nodes in the network of the loss of information. 


The context block is sent by the services platform over SS7 IMTs with 
the RLT capability until the Context Block reaches a switch whose 
originating trunk is not an SS7 IMT with RLT capability. The switch that 
holds the context block must physically exist where reorigination is 
handled. 


The information sent by the services platform in the context block is not 
parsed by the UCS DMS-250 switch and is not recorded in the billing 
record. 


Table RTEATTR controls the capability to include/exclude generic digits 
within IAM messages. 


Table TRKGRP’s PARMBLK excludes generic digits within IAM 
messages. 
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e The SS7 IMTs with RLT capabilities need to be network specific (the 
field NETWKSPC in table TRKGRP must be populated with INTER). 


e The option TMCICBLK_TNS needs to be placed on the SS7 IMTs on 
the UCS DMS-250 side, which prevents the TNS from being added to 
the IAM message. 


The trunks connecting the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the ESP platform are all ISUP intermachine trunks 
with RLT functionality. The trunk connecting the caller to the bridging 
switch is one of the following: 


e aper-trunk signaling (PTS) trunk 
e an ISUP FGD trunk 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Figure 5-1 is a high-level diagram of the boomerang reorigination scenario. 
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Figure 5-1 
Boomerang reorigination scenario 
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Message flow for boomerang reorigination scenario without the Context 
Block 


Figure 5-2 is a comprehensive message flow diagram for the boomerang 
reorigination scenario without the context block. It shows the sequence for 
the exchange of messages between the bridging UCS DMS-250 switch, the 
remote UCS DMS-250 switch, and the ESP. 


Specifically, the message exchange occurs as follows: 


1 Upon completion of the original call, the bridging switch releases the 
call’s terminator, but the call’s originator stays on line. 


2 The call’s originator presses the octathorpe (#) key to reoriginate the call. 
Upon reorigination, the bridging switch formats an Initial Address 
Message (IAM) and sends it to the remote switch. The remote switch 
passes the IAM to an ESP. Table 5-1 shows RLT-related parameters in 
the IAM. 


3 This IAM contains a Generic Digits (GD) parameter that includes a Call 
Identification (CALLID) value that identifies the previous call. The 
CALLID is obtained from either the Call Reference received in the 
Answer Message (ANM) or from the GD parameter received in the 
Facilities Request (FAR). 


— The ESP can send the CALLID value in the Call Reference of the 
ANM to the bridging UCS DMS-250 switch (refer to Note 2, Page 
3-18). If no CALLID is received in the GD of the FAR, the CALLID 
in the Call Reference of the ANM is used to populate the GD of the 
IAM. 


— The CALLID value obtained from the GD parameter of the FAR 
message is ESP generated as well. If the CALLID is received in the 
GD of the FAR, the CALLID in the GD of the FAR is used to 
populate the GD of the IAM. If the CALLID in the Call Reference of 
the ANM and the CALLID in the GD of the FAR are both received, 
the CALLID in the GD of the FAR takes precedence and is used to 
populate the GD of the IAM. 


Note: The CALLID referred to in this section is not the same as the 
UCS DMS-250 generated CALLID that the Bridging FAR messages 
contain in the Call Reference parameter. The UCS DMS-250 switch 
generated CALLID was used to identify the call identity of the second 
call leg which is used for bridging purposes. The Bridging FAR can be 
received with a CALLID (UCS DMS-250 generated) in the Call 
Reference parameter and a CALLID (ESP generated) in the GD 
parameter. Only the CALLID received in the GD parameter is used to 
populate the GD CALLID value sent in the IAM upon reorigination. 
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Table 5-1 
Important RLT parameters in first leg IAM 
RLT parameter Comments 
Called Party Number The switches use the number of the party called 


when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


Generic Digits This parameter contains the CALLID value from 
the original call. 


Charge Number This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


Calling Party Number This parameter contains an ANI value. The 
switches add this value to the ANI SPILL field in 
the call’s CDR, unless they pull the ANI value from 
the Charge Number parameter. 


Transit Network This parameter’s Reorigination Call field identifies 
Selector that the call is a boomerang reorigination call. 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


4 Using the appropriate means based on the call’s type, the ESP and 
switches process the call as described in other call scenarios. For ESP 
redirect and transfer calls, see steps 5-14 in the section titled “Message 
flow for the redirect and transfer scenario,” in Chapter 4 “Common RLT 
call scenarios.” For ESP third-party interaction calls, see steps 5—21 in 
the section titled “Message flow for third-party interaction,” in 
Chapter 4. 
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Figure 5-2 


Message flow for boomerang reorigination scenario without the context block 
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Message flow for boomerang reorigination with context block scenario 


Figure 5-3 is a comprehensive message flow diagram for the reorigination 
with context block scenario. Figure 5-4 shows the message flow diagram 
when an extension block is not available. These two figures illustrate a 
message flow diagram for a card services call which uses context blocks. 


Note: All switches in the network must have a UCS08 or higher software 
load in order to make use of the context block functionality. If the switches 
do not all have the required load installed, the call context block information 
gets lost. Because there is no explicit messaging, the nodes in the network 
do not receive the information contained in the call context block. 


Specifically, the message exchange occurs as follows: 


1 


10 


The calling party initiates an operator—related call requiring card 
validation. 


The services platform collects and validates the card information. 


The services platform sends the context block information to the switch 
in the context block FAR. When the services platform sends more than 
one context block FAR to the switch, the switch stores the most recent 
one. 


The switch sends back an FAA message to the services platform, 
indicating successful storage of the context block. 


The services platform sends a notice that subsequent reoriginations must 
be boomerang reoriginations in the operator information parameter of 
the bridging FAR. 


The UCS DMS-250 switch sends an FAA message back to the services 
platform indicating success of bridging. 


After the call bridges and the caller decides to reoriginate, the switch 
boomerangs the call back to the services platform (when reorigination is 
allowed). The new field in the generic digits parameter (located in the 
IAM message sent back to the services platform) indicates context block 
availability, as well as call state at the time of reorigination (connecting, 
talking, or disconnect). 


If the context block is required, the services platform sends a request for 
context block to the switch using the new request context block FAR. 


The switch sends the context block to the services platform in an FAA 
message. 


The services platform retrieves the context information, eliminating the 
need for reentry of information (calling card number or language, for 
example). 
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Figure 5-3 
Message flow for boomerang reorigination with context block scenario 
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Figure 5-3 
Message flow for boomerang reorigination with context block scenario 
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Figure 5-3 
Message flow for boomerang reorigination with context block (continued) 
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Message flow for boomerang reorigination with context block, 
extension block unavailable error scenario 


Reorigination functionality for card services calls depend on the availability 
of extension blocks. When there are not enough extension blocks available, 
an error occurs. The message flow when an extension block is unavailable 
follows: 


1 The services platform collects and validates the card information 


2 The services platform sends the context block information to the switch 
in the new Context_Block FAR. 


3 The UCS DMS-250 switch sends a Facility Reject (FRJ) message to the 
services platform indicating unsuccessful storage of the context block 
(cause value = 43 dec. User Information Discarded). A limited amount 
of extension blocks for the storage of context blocks at the UCS 
DMS-250 reoriginating switch causes this problem. 
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Figure 5-4 


Message flow for boomerang reorigination with context block, extension 
block unavailable scenario 
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Message flow for boomerang reorigination with context block not 
stored scenario 
The following text describes the message flow between the ESP and the 
UCS DMS-250 switch when a context block has not been stored for a card 
services call. Figure 5-5 shows the message flow scenario. 


i 
2 


The services platform collects and validates the card information. 


The services platform sends the context block information to the 
originating UCS DMS-250 switch in the new Context_Block FAR. 


The UCS DMS-250 switch sends a Facility Reject (FRJ) message to the 
services platform indicating unsuccessful storage of the context block 
(cause value = 43 dec. User Information Discarded). A limited amount 
of extension blocks for the storage of context blocks at the UCS 
DMS-250 reoriginating switch causes this problem. 


The services platform sends the indication that subsequent reoriginations 
should be boomerang reoriginations. The services platform initiates RLT 
bridging. 

After the call bridges and the caller decides to reoriginate, the UCS 
DMS-250 switch boomerangs the call back to the services platform. 


The UCS DMS-250 switch sends the IAM message back to the services 
platform without indication of the context block’s availability. 


The services platform sends a request for a context block to the UCS 
DMS-250 switch using the Request_Context_Block FAR. 


The UCS DMS-250 switch sends the FRJ message back to the services 
platform indicating that the context block is unavailable (cause value = 
47 dec.). 
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Figure 5-5 
Message flow for boomerang reorigination with context block not stored 
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Multiple Answer Message scenario 


Some ESPs allow a customer to select services options that require the ESP 
to route the call to another ESP. This ESP may also allow the customer to 
select services that route the call to subsequent ESPs. In this way, switches 
may generate multiple ANMs for one call involving several ESPs. 


For calls with multiple ANMs, the remote switch produces a CDR with a 
CALLDUR (call duration) value based on the time stamp for the last ANM 
it receives from an ESP. To set the switch to produce a CDR based on the 
first ANM that it receives from an ESP, set office parameter 
RLT_FIRST_ANM_BILLING to Y. (Refer to Page 2-13). The UCS 
DMS-250 switch and telecommunications network software determines 
which method the remote switch uses. 


Figure 5-6 is a high-level diagram of the Multiple Answer Message scenario. 


Table 5-2 shows how the switches determine CALLDUR values depending 
on the point at which the caller or switching network discontinues the call. It 
uses the ANM and ESP numbering shown in Figure 5-6. For more 
information on billing and the CALLDUR field for CDRs, see Chapter 7, 


“Billing for RLT calls.” 
Table 5-2 
CALLDUR value depending on point of disconnection 
Point of call CALLDUR based on time CALLDUR based on time 
disconnection stamp of first ANM stamp of last ANM 
ANM 1 Time at ESP 1 Time at ESP 1 
ANM 2 Time at ESP 1 + time at Time at ESP 2 only 
ESP 2 
ANM 3 Time at ESP 1 + time at Time at ESP 3 only 
ESP 2 + time at ESP 3 
ANM 4 Time at ESP 1 + time at Time at terminator (B) only 
ESP 2 + time at ESP 3 + 
time at terminator (B) 
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Figure 5-6 
Multiple Answer Message scenario 
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RLT call scenarios for non-operator 
(0+, O—) calls 


This chapter summarizes the flow of Signaling System 7 (SS7) Integrated 
Services Digital Network (ISDN) User Part (ISUP) messages between UCS 
DMS-250 switches and a services platform that supports Release Link Trunk 
(RLT) capabilities for non-operator calls. An Enhanced Services Provider 
(ESP) is an example of a services platform. An ESP platform is a system 
that provides specialized switching, billing, and call processing features. 


This chapter describes non-operator RLT scenarios for an ESP platform. 
Non-operator calls are calls without a 0— or 0+ address. Each scenario 
describes the SS7 ISUP messaging between a bridging UCS DMS-250 
switch, a remote UCS DMS-250 switch, and a services platform. The 
scenarios highlight parameters that the ISUP messages contain. For technical 
descriptions of messages and parameters, Refer to Chapter 3, “SS7 ISUP 
RLT messages and protocol.” 


When the office parameter ALL_RLT_OPR_CALLS is Y, the bridging and 
remote UCS DMS-250 switches treat all calls, including non-operator calls, 
as operator services calls. When this office parameter is set to N, these 
switches treat non-operator RLT calls differently than operator services calls, 
especially regarding reorigination functionality. By separating non-operator 
calls from operator services calls, the bridging and remote switches can 
allow non-operator calls to reoriginate before bridging, or reoriginate where 
no bridging occurs. 


Scenarios occurring when the originating switch allows normal 
reorigination at origination 
The following scenarios can occur when the originating switch allows 
normal reorigination at or upon origination: 
e Normal Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 


e Boomerang Reorigination in the REORIG_TYPE field in the ANM and 
the originating switch is the bridging switch 
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No Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 

Normal Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is different from the bridging switch 


Boomerang Reorigination in the REORIG_TYPE field in the ANM and 
the originating switch is different from the bridging switch 


No Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is different from the bridging switch 


Normal Reorigination in the REORIG_TYPE field in the ANM and the 
the services platform does not allow bridging 


Boomerang or No Reorigination in the REORIG_TYPE field in the 
ANM and the the services platform does not allow bridging 


The trunks connecting the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the services platform is an ISUP intermachine trunk 
(IMT) with RLT functionality. The trunk connecting the caller to the 
bridging switch is one of the following: 


a per-trunk signaling (PTS) trunk 

a primary rate interface (PRI) trunk 

an ISUP FGD trunk 

an ISUP IMT without RLT functionality 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 
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Normal Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 
Figure 6-1 is a comprehensive message flow diagram for this redirection 
scenario. It shows the sequence for the exchange of messages and 
parameters between the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the services platform. 


Specifically, the message exchange occurs as follows: 


1 The originating switch, the bridging switch in this scenario, receives a 
non-operator call and allows it to normally reoriginate. The switch 
allocates reorigination resources for the call. Then the switch issues an 
Initial Address Message (IAM) and sends it to another switch, the 
remote switch in this scenario. The IAM includes a standard Nature of 
Address and the IAM does not build a Generic Digits or Transit Network 
Selector parameter. 


2 Inresponse to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 6-1 shows parameters 
in this IAM that affect RLT functionality. 


Table 6-1 
RLT parameters in the IAM 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(Refer to Chapter 5, RLT call scenarios for ESP, 
for a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


3 The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the bridging 
switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Normal Reorigination. This ANM instructs the 
originating switch to continue to allocate reorigination resources for the 
call. Table 6-2 shows parameters in this ANM that affect RLT 
functionality. 


Table 6-2 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to No Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 6-3 shows parameters in this 
FAR message that affect RLT functionality. 


Table 6-3 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 
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7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. Table 6-4 
shows parameters in this FAA message that affect RLT functionality. 


Table 6-4 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 6-5 shows parameters in this 
FAR message that affect RLT functionality. 
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Table 6-5 


RLT parameters in the Redirect FAR message 


RLT parameter 


Facility Indicator 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s merged CDR and 
includes it in the call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


This parameter contains the CALLID value that the 
services platform can provide. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match the billing 
records on the services platform and bridging 
switch. 


10 The remote switch passes the FAR to the bridging switch. Because the 
trunk connecting the bridging switch to the switch from which it 
originally received the call does not support RLT functionality, it reads 
the message’s Facility Indicator and performs release link trunking. 
Using translations of the Called Party Number parameter, the bridging 
switch completes the call. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to Chapter 
5, “RLT call scenarios for ESP,” for a description of boomerang 


reorigination. 
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11 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 6-6 shows parameters in this 
FAA message that affect RLT functionality. 


Table 6-6 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


12 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


13 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


14 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. Table 6-7 shows the complete reorigination timeframe for this 


scenario. 
Table 6-7 
Reorigination timeframe 
Between the 

After origination Between the receipt of ANM After bridging 
to the receipt of receipt of ACM and bridging FAR to call 
ACM and ANM FAR takedown 
The switch The switch The switch The switch 
allows allows normal allows normal allows normal 
reorigination reorigination reorigination reorigination 
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Figure 6-1 


Message flow for non-operator RLT call scenarios (originating switch as 
bridging switch) 
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Figure 6-1 
Message flow for non-operator RLT call scenarios (continued) 
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Figure 6-1 


Message flow for non-operator RLT call scenarios (originating switch as 
bridging switch) (continued) 
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Boomerang Reorigination in the REORIG_TYPE field in the ANM and 
the originating switch is the bridging switch 
Figure 6-1 is a comprehensive message flow diagram for this redirection 
scenario. It shows the sequence for the exchange of messages and 
parameters between the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the services platform. 


Specifically, the message exchange occurs as follows: 


1 


The originating UCS DMS-250 switch, the bridging switch in this 
scenario, receives a non-operator call and allows it to normally 
reoriginate. The switch allocates reorigination resources to the call. The 
switch then issues an Initial Address Message (IAM) and sends it to 
another UCS DMS-250 switch, the remote switch in this scenario. The 
IAM includes a standard Nature of Address and the IAM does not build 
a Generic Digits or Transit Network Selector parameter. 


In response to the IAM from the bridging switch, the remote UCS 
DMS-250 switch sends another IAM to the services platform. Table 6-8 
shows parameters in this IAM that affect RLT functionality. 


Table 6-8 
RLT parameters in the IAM 


3 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, “RLT call scenarios for ESP,” 
for a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the bridging 
switch. 


When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Boomerang Reorigination. The originating switch 
deallocates reorigination resources for the call. Table 6-9 shows 
parameters in this ANM that affect RLT functionality. 
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Table 6-9 
RLT parameters in the ANM 
RLT parameter Comments 
Operator Information This parameter’s Reorigination Type field 


determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to Boomerang Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 6-10 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-10 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 
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Note I: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. Table 6-11 
shows parameters in this FAA message that affect RLT functionality. 


Table 6-11 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. Table 6-12 shows parameters in this FAR message 
that affect RLT functionality. 
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Table 6-12 


RLT parameters in the Redirect FAR message 


RLT parameter 


Facility Indicator 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and bridging 
switches. 


10 The remote switch passes the FAR to the bridging switch. Because the 
trunk connecting the bridging switch to the switch from which it 
originally received the call does not support RLT functionality, it reads 
the message’s Facility Indicator and performs release link trunking. 
Using translations of the Called Party Number parameter, the bridging 
switch completes the call. The switch will allocate reorigination 
resources, enabling boomerang reorigination. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to Chapter 
5, “RLT call scenarios for ESP,” for a description of boomerang 


reorigination. 
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11 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 6-13 shows parameters in this 
FAA message that affect RLT functionality. 


Table 6-13 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the “Release 
Link for Operator Redirect/Transfer” value that was 
in the FAR message. 


12 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


13 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


14 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. Table 6-14 shows the complete reorigination timeframe for this 


scenario. 
Table 6-14 
Reorigination timeframe 
Between the 
After origination Between the receipt of ANM After bridging 
to the receipt of receipt of ACM and bridging FAR to call 
ACM and ANM FAR takedown 
The switch does The switch The switch does The switch 
not allow allows normal not allow allows 
reorigination reorigination reorigination boomerang 
reorigination 
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No Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 
Figure 6-1 is a comprehensive message flow diagram for this scenario. It 
shows the sequence for the exchange of messages and parameters between 
the bridging UCS DMS-250 switch, the remote UCS DMS-250 switch, and 
the services platform. 


Specifically, the message exchange occurs as follows: 


1 The originating switch, the bridging switch in this scenario, receives a 
non-operator call and allows it to normally reoriginate. The switch 
allocates reorigination resources to the call. The switch then issues an 
Initial Address Message (IAM) and sends it to another switch, the 
remote switch in this scenario. The IAM includes a standard Nature of 
Address and the IAM does not build a Generic Digits or Transit Network 
Selector parameter. 


2 Inresponse to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 6-15 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-15 
RLT parameters in the IAM 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(ENSRO002). 


3 The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the bridging 
switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to No Reorigination. This ANM instructs the originating 
switch to deallocate reorigination resources for the call. Table 6-16 
shows parameters in this ANM that affect RLT functionality. 


Table 6-16 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to No Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 6-17 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-17 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 
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7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging UCS DMS—250 switch formats a Facility Accept (FAA) 
message and sends it to the remote switch, which passes it to the services 
platform. Table 6-18 shows parameters in this FAA message that affect 
RLT functionality. 


Table 6-18 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 6-19 shows parameters in this 
FAR message that affect RLT functionality. 
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Table 6-19 


RLT parameters in the Redirect FAR message 


RLT parameter 


Facility Indicator 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and bridging 
switch. 


10 The remote switch passes the FAR to the bridging switch. Because the 
trunk connecting the bridging switch to the switch from which it 
originally received the call does not support RLT functionality, it reads 
the message’s Facility Indicator and performs release link trunking. 
Using translations of the Called Party Number parameter, the bridging 
switch completes the second leg of the call. The switch will not allow 


reorigination. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to 
Chapter 5, “RLT call scenarios for ESP,” for a description of boomerang 


reorigination. 
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11 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 6-20 shows parameters in this 
FAA message that affect RLT functionality. 


Table 6-20 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator 


This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


12 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


13 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


14 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. Table 6-21 shows the complete reorigination timeframe for this 
scenario. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


Table 6-21 
Reorigination timeframe 


Between the 


After origination 
to the receipt of 
ACM 


The switch does 
not allow 
reorigination 


Between the 
receipt of ACM 
and ANM 


The switch 
allows normal 
reorigination 


receipt of ANM 
and bridging 
FAR 


The switch does 
not allow 
reorigination 


After bridging 
FAR to call 
takedown 


The switch 
allows normal 
reorigination 
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Normal Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is different from the bridging switch 
Figure 6-2 is a comprehensive message flow diagram for this scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the bridging UCS DMS-250 switch, 
and the services platform, when the originating switch is different from the 
bridging switch and normal reorigination is enabled by the ANM. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and allows it to 
normally reoriginate. The switch allocates reorigination resources to the 
call. The switch then issues an Initial Address Message (IAM) and sends 
it to another switch, the bridging switch in this scenario. The IAM 
includes a standard Nature of Address and the IAM does not build a 
Generic Digits or Transit Network Selector parameter. 


Note: The originating switch is not the bridging switch in this scenario. 
2 In response to the IAM from the originating switch, the bridging UCS 


DMS-250 switch sends another IAM to the services platform. Table 6-22 
shows parameters in this IAM that affect RLT functionality. 


Table 6-22 
RLT parameters in the IAM 


RLT parameter Comments 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(refer to Chapter 5, “RLT call scenarios for ESP,” 
for a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


3 The services platform returns an Address Complete message (ACM) to 
the bridging switch. The remote switch passes the ACM to the 
originating switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the bridging switch. The bridging switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Normal Reorigination. The reorigination resources then 
remain allocated for the call at the originating switch. Table 6-23 shows 
parameters in this ANM that affect RLT functionality. 


Table 6-23 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, the 
switches can perform for the call In this scenario, 
this field is set to Normal Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the bridging switch. Table 6-24 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-24 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The bridging switch checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 
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Note 1: In this example, the services platform, bridging, and originating 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between the remote and the 
originating switch in this scenario did not support release link trunking, 
the remote switch would not pass the FAR message, and would therefore 
be the bridging switch. 


7 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the services platform. Table 6-25 shows parameters in this FAA message 
that affect RLT functionality. 


Table 6-25 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


8 The services platform initiates release link trunking, sending another 
FAR message to the bridging switch. Table 6-26 shows parameters in 
this FAR message that affect RLT functionality. 
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Table 6-26 
RLT parameters in the Redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


Calling Party Number The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s merged CDR and 
includes it in the call’s OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform can provide. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and the bridging 
switch. 


9 Because the trunk connecting the bridging switch to the originating 
switch does not support RLT functionality, the bridging switch reads the 
message’s Facility Indicator and performs release link trunking. Using 
translations of the Called Party Number parameter, the bridging switch 
completes the second leg of the call. 


Note 1: The bridging FAR may contain new reorigination billing 
information. Since no new billing information is passed on to the 
originating switch, if reorigination occurs during the call, the old billing 
information stored in the originating switch is used to bill the 
reoriginated call. 
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10 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the services platform. 
Table 6-27 shows parameters in this FAA message that affect RLT 
functionality. 


Table 6-27 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


11 After bridging the call, the bridging switch formats a Release (REL) 
message, sends it to the services platform and releases the connection to 
the services platform and the corresponding trunks. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


12 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the bridging switch to confirm the 
release. Table 6-28 shows the complete reorigination timeframe for this 


scenario. 
Table 6-28 
Reorigination timeframe 
Between the 

After origination Between the receipt of ANM After bridging 
to the receipt of receipt of ACM and bridging FAR to call 
ACM and ANM FAR takedown 
The switch does The switch The switch The switch 
not allow allows normal allows normal allows normal 
reorigination reorigination reorigination reorigination 
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Figure 6-2 
Message flow for non-operator RLT call scenarios (originating switch not the bridging switch) 
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Figure 6-2 
Message flow for non-operator RLT call scenarios (originating switch not bridging switch) (continued) 
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Figure 6-2 
Message flow for non-operator RLT call scenarios (originating switch not bridging switch) (continued) 
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Boomerang Reorigination in the REORIG_TYPE field in the ANM and 
the originating switch is different from the bridging switch 


Figure 6-2 is a comprehensive message flow diagram for the scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the bridging UCS DMS-250 switch, 
and the services platform. In these scenarios, we assume that the originating 
switch is different from the bridging switch and Boomerang reorigination is 
enabled by the ANM. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and allows it to 
normally reoriginate. The switch allocates reorigination resources to the 
call. The switch then issues an Initial Address Message (IAM) and sends 
it to another switch, the bridging switch in this scenario. The IAM 
includes a standard Nature of Address and the IAM does not build a 
Generic Digits or Transit Network Selector parameter. 


Note: The originating switch is not the bridging switch in this scenario. 
2 In response to the IAM from the originating switch, the bridging switch 


sends another IAM to the services platform. Table 6-29 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-29 
RLT parameters in the IAM 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(ENSRO002). 


3 The services platform returns an Address Complete message (ACM) to 
the bridging switch. The bridging switch passes the ACM to the 
originating switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the bridging switch. The bridging switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Boomerang Reorigination. The originating switch 
deallocates reorigination resources for the call. Table 6-30 shows 
parameters in this ANM that affect RLT functionality. 


Table 6-30 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to Boomerang Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the bridging switch. Table 6-31 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-31 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The bridging switch checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 


message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 
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Note 1: In this example, the services platform, bridging, and remote 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between the remote switch and 
the originating switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


7 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the services platform. Table 6-32 shows parameters in this FAA message 
that affect RLT functionality. 


Table 6-32 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the same Start 
Billing Time value that was in the FAR message. 


8 The services platform initiates release link trunking, sending another 
FAR message to the bridging switch. Table 6-33 shows parameters in 
this FAR message that affect RLT functionality. 
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Table 6-33 
RLT parameters in the Redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


Calling Party Number The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s merged CDR and 
includes it in the call’s OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


Generic Digits This parameter contains the CALLID value that the 
that the services platform can provide. The 
bridging switch places this value in the CALLID 
field in the OSR for the call and uses the value to 
match billing records on the services platform and 
bridging switch. 


9 Because the trunk connecting the bridging switch to the switch from 
which it originally received the call does not support RLT functionality, 
it reads the message’s Facility Indicator and performs release link 
trunking. Using translations of the Called Party Number parameter, the 
bridging switch completes the second leg of the call. 


10 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the services platform. 
Table 6-34 shows parameters in this FAA message that affect RLT 
functionality. 
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Table 6-34 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


11 After bridging the call, the bridging switch formats a Release (REL) 
message, sends it to the services platform, and releases the connection to 
the services platform and the corresponding trunks. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


12 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the bridging switch to confirm the 
release. Table 6-35 shows the complete reorigination timeframe for this 


scenario. 
Table 6-35 
Reorigination timeframe 
Between the 

After origination Between the receipt of ANM After bridging 
to the receipt of receipt of ACM and bridging FAR to call 
ACM and ANM FAR takedown 
The switch does The switch The switch does The switch does 
not allow allows normal not allow not allow 
reorigination reorigination reorigination reorigination 
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No Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is different from the bridging switch 


Figure 6-2 is a comprehensive message flow diagram for the scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the bridging UCS DMS-250 switch, 
and the services platform. In this scenario, we assume the originating switch 
is different from the bridging switch and no reorigination is enabled by the 
ANM. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and allows it to 
normally reoriginate. The switch allocates reorigination resources to the 
call. The switch then issues an Initial Address Message (IAM) and sends 
it to another switch, the bridging switch in this scenario. The IAM 
includes a standard Nature of Address and the IAM does not build a 
Generic Digits or Transit Network Selector parameter. 


Note: The originating switch is not the bridging switch in this scenario. 
2 In response to the IAM from the originating switch, the bridging switch 


sends another IAM to the services platform. Table 6-36 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-36 
RLT parameters in the IAM 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(ENSRO002). 


3 The services platform returns an Address Complete message (ACM) to 
the bridging switch. The bridging switch passes the ACM to the 
originating switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the bridging switch. The bridging switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to No Reorigination. This ANM instructs the originating 
switch to deallocate reorigination resources for the call. Table 6-37 
shows parameters in this ANM that affect RLT functionality. 


Table 6-37 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to No Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the bridging switch. Table 6-38 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-38 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The bridging switch checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 


message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 
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Note 1: In this example, the services platform, bridging, and originating 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the remote and the 
originating switch in this scenario did not support release link trunking, 
the remote switch would not pass the FAR message, and would therefore 
be the bridging switch. 


7 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the services platform. Table 6-39 shows parameters in this FAA message 
that affect RLT functionality. 


Table 6-39 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


8 The services platform initiates release link trunking, sending another 
FAR message to the bridging switch. Table 6-40 shows parameters in 
this FAR message that affect RLT functionality. 
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Table 6-40 


RLT parameters in the Redirect FAR message 


RLT parameter 


Facility Indicator 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


This parameter contains the CALLID value that the 
service platform can provide. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and the bridging 
switch. 


9 Because the trunk connecting the bridging switch to the switch from 
which it originally received the call does not support RLT functionality, 
it reads the message’s Facility Indicator and performs release link 
trunking. Using translations of the Called Party Number parameter, the 
bridging switch completes the call. 


10 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the services platform. 
Table 6-41 shows parameters in this FAA message that affect RLT 


functionality. 
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Table 6-41 


RLT parameters in the Redirect FAA message 


RLT parameter 


Comments 


Facility Indicator 


This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 

Link for Operator Redirect/Transfer value that was 
in the FAR message. 


11 After bridging the call, the bridging switch formats a Release (REL) 
message, sends it to the services platform, and releases the connection to 
the services platform and the corresponding trunks. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


12 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the bridging switch to confirm the 
release. Table 6-42 shows the complete reorigination timeframe for this 


scenario. 


Table 6-42 


Reorigination timeframe 


After origination 
to the receipt of 
ACM 


The switch does 
not allow 
reorigination 


Between the 


receipt of ACM 
and ANM 


The switch 
allows normal 
reorigination 


Between the 
receipt of ANM 
and bridging 
FAR 


The switch does 
not allow 
reorigination 


After bridging 
FAR to call 
takedown 


The switch does 
not allow 
reorigination 
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Normal Reorigination in the REORIG_TYPE field in the ANM and the 
services platform does not allow bridging 
Figure 6-3 is a comprehensive message flow diagram for this scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the remote UCS DMS-250 switch, 
and the services platform. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and allows it to 
normally reoriginate. The switch allocates reorigination resources to the 
call. The switch then issues an Initial Address Message (IAM) and sends 
it to another switch, the remote switch in this scenario. The IAM 
includes a standard Nature of Address and the IAM does not build a 
Generic Digits or Transit Network Selector parameter. 


Note: The services platform does not allow bridging during this 
scenario. 


2 In response to the IAM from the originating switch, the remote switch 
sends another IAM to the services platform. Table 6-43 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-43 
RLT parameters in the IAM 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


3 The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the originating 
switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Normal Reorigination. The reorigination resources for 
the call remain allocated on the originating switch. Table 6-44 shows 
parameters in this ANM that affect RLT functionality. 


Table 6-44 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to No Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, and makes the call to 
that party. Table 6-45 shows the complete reorigination timeframe for 
this scenario. 


Table 6-45 
Reorigination timeframe 


Between the receipt 
After origination to Between the receipt of ANM to call 
the receipt of ACM of ACM and ANM takedown 
The switch does not The switch allows The switch allows 
allow reorigination normal reorigination normal reorigination 
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Figure 6-3 
Message flow for non-operator RLT call scenarios (bridging not allowed) 
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Boomerang Reorigination in the REORIG_TYPE field in the ANM and 
the services platform does not allow bridging 


Figure 6-3 is a comprehensive message flow diagram for the scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the remote UCS DMS-250 switch, 
and the services platform, when the services platform does not allow 
bridging. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and allows it to 
normally reoriginate. The switch allocates reorigination resources to the 
call. The switch then issues an Initial Address Message (IAM) and sends 
it to another switch, the remote switch in this scenario. The IAM 
includes a standard Nature of Address and the IAM does not build a 
Generic Digits or Transit Network Selector parameter. 


Note: The services platform does not allow bridging in this scenario. 
2 Inresponse to the IAM from the originating switch, the remote switch 


sends another IAM to the services platform. Table 6-46 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-46 
RLT parameters in the IAM 


RLT parameter Comments 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(refer to Chapter 5, “RLT call scenarios for ESP,” 
for a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(ENSR0002). 


3 The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the originating 
switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Boomerang Origination or No Reorigination. This ANM 
instructs the originating switch to deallocate reorigination resources for 
the call. Table 6-47 shows parameters in this ANM that affect RLT 
functionality. 


Table 6-47 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call In this message, 
this field is set to Boomerang or No Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, and makes the call to 
that party. Table 6-48 shows the complete reorigination timeframe for 
this scenario. 


Table 6-48 
Reorigination timeframe 


Between the receipt 
After origination to Between the receipt of ANM to call 
the receipt of ACM of ACM and ANM takedown 
The switch does not The switch allows The switch does not 
allow reorigination normal reorigination allow normal 
reorigination 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


6-44 Non-Operator RLT call scenarios 


Scenarios occurring when the originating switch does not allow 
normal reorigination at origination 


The following scenarios can occur when the originating switch does not 
allow normal reorigination: 


Normal Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 

Boomerang Reorigination in the REORIG_TYPE field in the ANM and 
the originating switch is the bridging switch 

No Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 


Normal, Boomerang, or No Reorigination in the REORIG_TYPE field 
in the ANM and the originating switch is different from the bridging 
switch 


Normal Reorigination in the REORIG_TYPE field in the ANM and the 
the services platform does not allow bridging 


Boomerang or No Reorigination in the REORIG_TYPE field in the 
ANM and the the services platform does not allow bridging 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 
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Normal Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 
Figure 6-4 is a comprehensive message flow diagram for the scenario. It 
shows the sequence for the exchange of messages and parameters between 
the bridging UCS DMS-250 switch, the remote UCS DMS-250 switch, and 
the services platform. 


Specifically, the message exchange occurs as follows: 


1 


The originating switch, the bridging switch in this scenario, receives a 
non-operator call and does not allow it to normally reoriginate. The 
switch does not allocate reorigination resources to the call. The switch 
then issues an Initial Address Message (IAM) and sends it to another 
switch, the remote switch in this scenario. The IAM includes a standard 
Nature of Address and the IAM does not build a Generic Digits or 
Transit Network Selector parameter. 


In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 6-49 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-49 
RLT parameters in the IAM 


3 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the bridging 
switch. 


When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Normal Reorigination. This ANM instructs the 
originating switch to not allocate reorigination resources for the call. 
Table 6-50 shows parameters in this ANM that affect RLT functionality. 
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Table 6-50 
RLT parameters in the ANM 
RLT parameter Comments 
Operator Information This parameter’s Reorigination Type field 


determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to Normal Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 6-51 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-51 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 


297-2621-345 Standard 04.02 November 1999 


Non-Operator RLT call scenarios 6-47 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. Table 6-52 
shows parameters in this FAA message that affect RLT functionality. 


Table 6-52 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 6-53 shows parameters in this 
FAR message that affect RLT functionality. 
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Table 6-53 
RLT parameters in the Redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


Calling Party Number The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s merged CDR and 
includes it in the call’s OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform can provide. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and bridging 
switch. 


10 The remote switch passes the FAR to the bridging switch. Because the 
trunk connecting the bridging switch to the switch from which it 
originally received the call does not support RLT functionality, it reads 
the message’s Facility Indicator and performs release link trunking. 
Using translations of the Called Party Number parameter, the bridging 
switch completes the call. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to 

Chapter 5, “RLT call scenarios for ESP,” for a description of boomerang 
reorigination. 
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11 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 6-54 shows parameters in this 
FAA message that affect RLT functionality. 


Table 6-54 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


12 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


13 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


14 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. Table 6-55 shows the complete reorigination timeframe for this 
scenario. 


Table 6-55 
Reorigination timeframe 


Between the 


After origination Between the receipt of ANM After bridging 
to the receipt of receipt of ACM and bridging FAR to call 
ACM and ANM FAR takedown 


The switch does The switch does The switch does The switch 
not allow not allow not allow allows normal 
reorigination reorigination reorigination reorigination 
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Figure 6-4 
Message flow for non-operator RLT call scenarios (originating switch is bridging switch and 
normal reorigination not allowed) 
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Figure 6-4 
Message flow for non-operator RLT call scenarios (originating switch is bridging switch and normal 
reorigination not allowed) (continued) 
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Figure 6-4 


Message flow for non-operator RLT call scenarios (originating switch is bridging switch and normal 
reorigination not allowed) (continued) 
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Boomerang Reorigination in the REORIG_TYPE field in the ANM and 
the originating switch is the bridging switch 
Figure 6-4 is a comprehensive message flow diagram for this scenario. It 
shows the sequence for the exchange of messages and parameters between 
the bridging UCS DMS-250 switch, the remote UCS DMS-250 switch, and 
the services platform. 


Specifically, the message exchange occurs as follows: 


1 


The originating switch, the bridging switch in this scenario, receives a 
non-operator call and does not allow it to normally reoriginate. The 
switch does not allocate reorigination resources to the call. The switch 
then issues an Initial Address Message (IAM) and sends it to another 
switch, the remote switch in this scenario. The IAM includes a standard 
Nature of Address and the IAM does not build a Generic Digits or 
Transit Network Selector parameter. 


In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 6-56 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-56 
RLT parameters in the IAM 


3 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the bridging 
switch. 


When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Boomerang Reorigination. This ANM instructs the 
originating switch to not allocate reorigination resources for the call. 
Table 6-57 shows parameters in this ANM that affect RLT functionality. 
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Table 6-57 
RLT parameters in the ANM 
RLT parameter Comments 
Operator Information This parameter’s Reorigination Type field 


determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to Boomerang Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 6-58 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-58 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this message, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 


297-2621-345 Standard 04.02 November 1999 


Non-Operator RLT call scenarios 6-55 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. Table 6-59 
shows parameters in this FAA message that affect RLT functionality. 


Table 6-59 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 6-60 shows parameters in this 
FAR message that affect RLT functionality. 
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Table 6-60 


RLT parameters in the Redirect FAR message 


RLT parameter 


Facility Indicator 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


This parameter contains the CALLID value that the 
services platform can provide. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and bridging 
switch. 


10 The remote switch passes the FAR to the bridging switch. Because the 
trunk connecting the bridging switch to the switch from which it 
originally received the call does not support RLT functionality, it reads 
the message’s Facility Indicator and performs release link trunking. 
Using translations of the Called Party Number parameter, the bridging 
switch completes the call. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to 
Chapter 5, “RLT call scenarios for ESP,” for a description of boomerang 


reorigination. 


297-2621-345 Standard 04.02 November 1999 


Non-Operator RLT call scenarios 6-57 


11 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 6-61 shows parameters in this 
FAA message that affect RLT functionality. 


Table 6-61 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


12 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


13 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


14 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. Table 6-62 shows the complete reorigination timeframe for this 
scenario. 
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Table 6-62 
Reorigination timeframe 


After origination 


to the receipt of 
ACM 


Between the 
receipt of ACM 
and ANM 


Between the 
receipt of ANM 
and bridging 
FAR 


After bridging 
FAR to call 
takedown 


The switch does 
not allow 
reorigination 


The switch does 
not allow 
reorigination 


The switch does 
not allow 
reorigination 


The switch 
allows 
boomerang 
reorigination 
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No Reorigination in the REORIG_TYPE field in the ANM and the 
originating switch is the bridging switch 
Figure 6-4 is a comprehensive message flow diagram for the scenario. It 
shows the sequence for the exchange of messages and parameters between 
the bridging UCS DMS-250 switch, the remote UCS DMS-250 switch, and 
the services platform. 


Specifically, the message exchange occurs as follows: 


1 


The originating switch, the bridging switch in this scenario, receives a 
non-operator call and does not allow it to normally reoriginate. The 
switch does not allocate reorigination resources to the call. The switch 
then issues an Initial Address Message (IAM) and sends it to another 
switch, the remote switch in this scenario. The IAM includes a standard 
Nature of Address and the IAM does not build a Generic Digits or 
Transit Network Selector parameter. 


In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 6-63 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-63 
RLT parameters in the IAM 


3 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, “RLT call scenarios for ESP,” 
for a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the bridging 
switch. 


When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Boomerang Reorigination. This ANM instructs the 
originating switch to deallocate reorigination resources for the call. 
Table 6-64 shows parameters in this ANM that affect RLT functionality. 
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Table 6-64 
RLT parameters in the ANM 
RLT parameter Comments 
Operator Information This parameter’s Reorigination Type field 


determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to Boomerang Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 6-65 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-65 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 
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Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 connects to another switch across a trunk that does not 
support RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. Table 6-66 
shows parameters in this FAA message that affect RLT functionality. 


Table 6-66 
RLT parameters in the Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this message, it contains the same Start 
Billing Time value that was in the FAR message. 


9 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 6-67 shows parameters in this 
FAR message that affect RLT functionality. 
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Table 6-67 


RLT parameters in the Redirect FAR message 


RLT parameter 


Facility Indicator 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


This parameter contains the CALLID value that the 
services platform can provide. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and bridging 
switch. 


10 The remote switch passes the FAR to the bridging switch. Because the 
trunk connecting the bridging switch to the switch from which it 
originally received the call does not support RLT functionality, it reads 
the message’s Facility Indicator and performs release link trunking. 
Using translations of the Called Party Number parameter, the bridging 
switch completes the call. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to 
Chapter 5, “RLT call scenarios for ESP,” for a description of boomerang 


reorigination. 


297-2621-345 Standard 04.02 November 1999 


Non-Operator RLT call scenarios 6-63 


11 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. Table 6-68 shows parameters in this 
FAA message that affect RLT functionality. 


Table 6-68 
RLT parameters in the Redirect FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the Release 
Link for Operator Redirect/Transfer value that was 
in the FAR message. 


12 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


13 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


14 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. Table 6-69 shows the complete reorigination timeframe for this 
scenario. 


Table 6-69 
Reorigination timeframe 


Between the 


After origination Between the receipt of ANM After bridging 
to the receipt of receipt of ACM and bridging FAR to call 
ACM and ANM FAR takedown 


The switch does The switch does The switch does The switch does 
not allow not allow not allow not allow 
reorigination reorigination reorigination reorigination 
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Normal, Boomerang, or No Reorigination in the REORIG_TYPE field in 

the ANM and the originating switch is different from the bridging switch 
Figure 6-5 is a comprehensive message flow diagram for this scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the bridging UCS DMS-250 switch, 
and the services platform. In this scenario, we assume that the originating 
switch is different from the bridging switch and the ANM enables normal, 
boomerang, or no origination. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and does not allow it 
to normally reoriginate. The switch does not allocate reorigination 
resources to the call. The switch then issues an Initial Address Message 
(IAM) and sends it to another switch, the bridging switch in this 
scenario. The IAM includes a standard Nature of Address and the IAM 
does not build a Generic Digits or Transit Network Selector parameter. 


Note: The originating switch is not the bridging switch in this scenario. 
2 Inresponse to the IAM from the originating switch, the bridging switch 


sends another IAM to the services platform. Table 6-70 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-70 
RLT parameters in the IAM 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLTO002). 


3 The services platform returns an Address Complete message (ACM) to 
the bridging switch. The bridging switch passes the ACM to the 
originating switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the bridging switch. The bridging switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Normal Reorigination, Boomerang Reorigination, or No 
Reorigination. This ANM instructs the originating switch on whether or 
not to allocate reorigination resources for the call. Table 6-71 shows 
parameters in this ANM that affect RLT functionality. 


Table 6-71 


RLT parameters in the ANM 


RLT parameter 


Operator Information 


Comments 


This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call. In this case, this 
field is set to either Normal, Boomerang, or No 
Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the bridging switch. Table 6-72 shows parameters in 
this FAR message that affect RLT functionality. 


Table 6-72 


RLT parameters in the billing FAR message 


RLT parameter 


Facility Indicator 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 
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6 The bridging switch checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this message, the indicator 
starts billing. 


Note 1: In this example, the services platform, bridging, and originating 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between a remote switch and 
the originating switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


7 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the services platform. Table 6-73 shows parameters in this FAA message 
that affect RLT functionality. 


Table 6-73 
Important RLT parameters in this Billing FAA message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the same Start 
Billing Time value that was in the FAR message. 


8 The services platform initiates release link trunking, sending another 
FAR message to the bridging switch. Table 6-74 shows parameters in 
this FAR message that affect RLT functionality. 
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Table 6-74 


RLT parameters in the Redirect FAR message 


RLT parameter 


Facility Indicator 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
“Release Link for Operator Redirect/Transfer” 
value that the bridging switch uses. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s merged CDR and 
includes it in the call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s merged CDR and includes it in the 
OSR. 


This parameter contains the CALLID value that the 
services platform can provide. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match billing 
records on the services platform and bridging 
switch. 


9 Because the trunk connecting the bridging switch to the switch from 
which it originally received the call does not support RLT functionality, 
it reads the message’s Facility Indicator and performs release link 
trunking. Using translations of the Called Party Number parameter, the 
bridging switch completes the call. 


Note: If the Called Party Number parameter contains an NOO services 
number, the switch supports boomerang reorigination. Refer to 
Chapter 5, “RLT call scenarios for ESP,” for a description of boomerang 


reorigination. 
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10 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the services platform. 
Table 6-75 shows parameters in this FAA message that affect RLT 
functionality. 


Table 6-75 
Important RLT parameters in this Redirect FAA message 


RLT parameter Comments 


Facility Indicator 


This parameter defines the specific action that the 
FAR message requested at the bridging or remote 
switch. In this scenario, it contains the “Release 
Link for Operator Redirect/Transfer” value that was 
in the FAR message. 


11 After bridging the call, the bridging switch formats a Release (REL) 
message, sends it to the services platform and releases the connection to 
the services platform and the corresponding trunks. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


12 The services platform also releases its connections and returns a RLC 
with a proper Cause Indicator to the bridging switch to confirm the 
release. Table 6-76 shows the complete reorigination timeframe for this 
scenario. 


Table 6-76 
Reorigination timeframe 


Between the 


After origination Between the receipt of ANM After bridging 
to the receipt of receipt of ACM and bridging FAR to call 
ACM and ANM FAR takedown 


The switch does 
not allow 
reorigination 


The switch does 
not allow 
reorigination 


The switch does 
not allow 
reorigination 


The switch does 
not allow 
reorigination 
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Figure 6-5 
Message flow for non-operator RLT call scenarios (originating switch not bridging switch 


Services platform 


Originating Bridging 
switch switch 


Nature of Connection 
Forward Call Indicator 
Calling Party’s Category 


User Service Information . ; 
Calling Party’s Category 
Called Party: Number User Service Information 


Calling Party Number Called Party Number 


Generic Digits ; 

Calling Party Number 
Charg e Ni umber . Generic Digits 
Originating Line Information Charge Number 


Transit Network Selector Originating Line Information 
Transit Network Selector 


Backward Call Indicator 
Operator Information 


Nature of Connection 
Forward Call Indicator 


Backward Call Indicator 


Operator Information 


Start billing 


Facility Indicator 


Legend: Parameters 
Bold = Mandatory Regular = Optional 


Italics =Required for RLT functionality 


—continued— 
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Figure 6-5 


Message flow for non-operator RLT call scenarios (originating switch is not bridging switch and) 
(continued) 
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—continued— 
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Figure 6-5 
Message flow for non-operator RLT call scenarios (originating switch is not bridging switch and) 
(continued) 
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—end— 
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Normal Reorigination in the REORIG_TYPE field in the ANM and the 
services platform does not allow bridging 


Figure 6-6 is a comprehensive message flow diagram for this scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the remote UCS DMS-250 switch, 
and the services platform. In this scenario, we assume that the services 
platform does not allow bridging, and normal reorigination is enabled by the 
ANM. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and does not allow it 
to normally reoriginate. The switch does not allocate reorigination 
resources to the call. The switch then issues an Initial Address Message 
(IAM) and sends it to another switch, the remote switch in this scenario. 
The IAM includes a standard Nature of Address and the IAM does not 
build a Generic Digits or Transit Network Selector parameter. 


Note: The services platform does not allow bridging during this 
scenario. 


2 In response to the IAM from the originating switch, the remote switch 
sends another IAM to the services platform. Table 6-77 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-77 

RLT parameters in the IAM 
RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


3 The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the originating 
switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Normal Reorigination. This ANM instructs the 
originating switch to deallocate reorigination resources for the call. 
Table 6-78 shows parameters in this ANM that affect RLT functionality. 


Table 6-78 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call In this scenario, 
this field is set to Normal Reorigination. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the feature (URLT0002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party and makes the call to 
that party. Table 6-79 shows the complete reorigination timeframe for 
this scenario. 


Table 6-79 
Reorigination timeframe 


Between the receipt 
After origination to Between the receipt of ANM to call 
the receipt of ACM of ACM and ANM takedown 
The switch does not The switch does not The switch does not 
allow reorigination allow reorigination allow reorigination 
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Figure 6-6 
Message flow for non-operator RLT call scenarios (bridging not allowed) 
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Boomerang or No Reorigination in the REORIG_TYPE field in the ANM 
and the services platform does not allow bridging 


Figure 6-6 is a comprehensive message flow diagram for the scenario. It 
shows the sequence for the exchange of messages and parameters between 
the originating UCS DMS-250 switch, the remote UCS DMS-250 switch, 
and the services platform. In this scenario, we assume the services platform 
does not allow bridging, and boomerang or no reorigination is enabled by 
the ANM. 


Specifically, the message exchange occurs as follows: 


1 The originating switch receives a non-operator call and does not allow it 
to normally reoriginate. The switch does not allocate reorigination 
resources to the call. The switch then issues an Initial Address Message 
(IAM) and sends it to another switch, the remote switch in this scenario. 
The IAM includes a standard Nature of Address and the IAM does not 
build a Generic Digits or Transit Network Selector parameter. 


Note: The services platform does not allow bridging in this scenario. 
2 Inresponse to the IAM from the originating switch, the remote switch 


sends another IAM to the services platform. Table 6-80 shows 
parameters in this IAM that affect RLT functionality. 


Table 6-80 
RLT parameters in the IAM 


RLT parameter Comments 
Transit Network This parameter’s Reorigination Call field identifies 
Selector whether the call is a boomerang reorigination call 


(refer to Chapter 5, RLT call scenarios for ESP, for 
a description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLTO002). 


3 The services platform returns an Address Complete message (ACM) to 
the remote switch. The remote switch passes the ACM to the originating 
switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the originating switch. The ANM 
contains the REORIGINATION_TYPE field in the Operator Information 
parameter set to Boomerang Reorigination or No Reorigination. This 
ANM instructs the originating switch to not allocate reorigination 
resources for the call. Table 6-81 shows parameters in this ANM that 
affect RLT functionality. 


Table 6-81 
RLT parameters in the ANM 


RLT parameter Comments 


Operator Information This parameter’s Reorigination Type field 
determines what type of reorigination, if any, 
switches can perform for the call. 


Note 1: The ANM includes a Call Reference or Operator Information 
parameter only when the switch has the Enhanced Reorigination for Operator 
Services feature (URLTO002). 


Note 2: Only ESPs with proper programming return this parameter in ANMs. 


5 The services platform identifies the called party and makes the call to 
that party. Table 6-82 shows a complete reorigination timeframe for this 
scenario. 


Table 6-82 
Reorigination timeframe 


Between the receipt 
After origination to Between the receipt of ANM to call 
the receipt of ACM of ACM and ANM takedown 
The switch does not The switch allows The switch does not 
allow reorigination normal reorigination allow normal 
reorigination 
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Billing for RLT calls 


Using the Release Link Trunk (RLT) functionality, UCS DMS-250 switches 
can generate an operator service record (OSR), call detail record (CDR), or 
both for RLT calls. RLT functionality does not change the UCS DMS-250 
switch’s standard OSR or CDR. 


The type of services platform, such as an Enhanced Services Provider (ESP) 
determines what billing records the switches produce. When an RLT call is 
complete, the bridging switch produces an OSR and CDR pair for calls to 
the services platform. 


Note: The UCS12 software release does not support Enhanced Operator 
Position System (EOPS) functionality. The UCS software continues to 
support operator assisted calls through other platforms such as the ESP. 
Refer to Appendix A in the UCS DMS-250 Feature Change Reference Guide 
for additional information about EOPS removal. 


RLT billing when services platform is an ESP 


When the services platform is an ESP, the switches might or might not 
generate billing records; the nature of its billing records depends entirely on 
the ESP’s specific implementation. Chapter 8 describes common RLT billing 
scenarios when the ESP overrides the UCS DMS-250 switches and 
populates certain fields in the CDR. 


Office parameter for OSR generation 


To generate an OSR, the configuration of any UCS DMS-250 bridging 
switch must include Operator recording units and UCS DMS-250 recording 
units. The NO_OF_EOPS_REC_UNITS office parameter in table OFCENG 
allocates the number of Operator recording units that a switch has available. 
When a switch that bridges an RLT call lacks Operator recording units, it 
generates an appropriate log report. Chapter 1, “RLT functionality,” 
describes other office parameters that affect RLT billing. 


Note: The originator of any RLT call receives the bill; the call’s terminator 
does not. 
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Tables 7-1 and 7-2 provide examples of the OSR and CDR and the values 
that the records contain. The UCS12 software release does not support the 
RTELIST field. The UCSO7 software release supports the RTELIST field 


Table 7-1 


UCS CDR fields at the bridging switch 


Field name 


RECCD 
DISCDATE 
CNPREDIG 
ANSTYPE 
PINDIGS 
ORIGTIME 
QUEUED 
DISCTIME 
TIMECHNG 
ANISP 
INFODIG 
CALLDUR 


UNIVACG 


COMPCODE 


Example 


0 


Value from first or second CDR 


always FO for CDR 

upon disconnect after bridge 

first 

second (first for redirect scenario) 
second, if available, otherwise first 
first 

second (first for redirect scenario) 
upon disconnect after bridge 
second (first for redirect scenario) 
first 

first 

second (first for redirect scenario if a hotel or 


motel) 


Note: Switches calculate the CALLDUR 
either as the time from the last Answer 
Message (ANM) to disconnect or as the time 
from the first ANM to disconnect. For calls 
with multiple ANMs, the remote switch 
produces a CDR with a CALLDUR value 
based on the time stamp for the last ANM. To 
set the switch to produce CDR with 
CALLDUR based on the first ANM that it 
receives from an ESP, set office parameter 
RLT_FIRST_ANM_BILLING to Y. Your switch 
and telecommunications network software 
determine which method the remote switch 
uses. 


first 


second (first for redirect scenario) 


—continued— 
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Table 7-1 
UCS CDR fields at the bridging switch (continued) 
Field name Example Value from first or second CDR 
DIALEDNO 2149974500 first 
COLLTIME 002 second (first for redirect scenario) 
CALLEDNO 2149974500 second (first for redirect scenario) 
RTENO 00 second (first for redirect scenario) 
PREDIG 0 second (first for redirect scenario) 
OPART 511 first 
ADIN second (if not available, first for redirect 
scenario) 
ORIGOPRT 511 second (if not available, first for redirect 
scenario) 
SEQNUM 35796 second 
ORIGDATE 111 first 
FINSID second 
TRIMTCD 000 second 
TPART 31 first 
RTELIST 0007 second 
ANISUFF first 
DISCTYPE 0 first 
ORIGGRP 0392 first 
ORIGMEM 0110 first 
DIGDATA N second 
TRAP N first 
TERMGRP 0355 second 
TERMEM 0111 second 
COSOVE N first 
FINTKGRP second 
—continued— 
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Table 7-1 


UCS CDR fields at the bridging switch (continued) 


Field name 


BILLNUM 
ACCTCD 


Example 


Value from first or second CDR 


first 


second, if available, otherwise first 


—end— 


Table 7-2 


UCS OSR fields for OSR generated at the non-operator switch 


Field name 


RECCODE 


ENTCODE 
INFODIGS 
SERVFEAT 


CALLNGNO 
CALLDNO 
EVENTDIG 
STARTTME 


OPERNUMB 


Example 
F1 
27 


00 
00 


2149911212 
0 
002130353 


0002 


Message 

Facility Request (FAR) message: Called 
Party Number parameter 

FAR: Operator Information parameter 
upon disconnect 


IAM: Originating Line Information parameter 


FAR: Originating Line Information parameter 
FAR: Calling Party Number or CDR 

FAR: Called Party Number or CDR 

upon disconnect 


FAR: Facility Indicator 


Note: The STARTTME field is the time when 
the called party answers. For unanswered 
calls, however, it is the time of the initial trunk 
seizure. When the call is answered while the 
operator is still connected to the call, 
STARTIME corresponds to answer time. 
When a switch bridges the call before it is 
answered, STARTTME is the initial trunk 
seizure time. 


FAR: Operator Information 


—continued— 
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Table 7-2 
UCS OSR fields for OSR generaied at the non-operator switch (continued) 

Field name Example Message 

ELPSDTME 000002 upon disconnect 
Note: ELPSDTME is either the time from 
answer to disconnect or the start time 
(STARTTME) value received in the FAR to 
disconnect. To determine whether to use the 
answer time or the start time, switches use 
whichever they last received. If the call is not 
answered and the switches do not receive a 
start time, the ELPSDTME value is 0. 

TRDIGS 00 default 

CNOVTRCL not used 

EOPSINFO 0000 FAR 

TEAMNUMB not used 

TRBLCODE FAR: Operator Information 

BILLCODE not used 

INDIC FAR: Charge Adjust 

BILLNUMB 6038020000 FAR: Charge Number 

ADJTYPE FAR: Charge Adjust 

ROOMNUMB FAR: Generic Digits 

ADJENTRY FAR: Charge Adjust 

GUEST FAR: Generic Digits 

HOTELTAX not used 

QUOTEAMT not used 

ADJTIME FAR: Charge Adjust 

ADJAMT FAR: Charge Adjust 

SEQNUMB 00029 from CDR 

WALKAWAY not used 

SSASCODE not used 

COIN N default 

SWID 111 table OFCVAR ORIG_SWITCH_ID 

—continued— 
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Table 7-2 
UCS OSR fields for OSR generaied at the non-operator switch (continued) 
Field name Example Message 
CNCREDIT not used 
SSASIND not used 
—end— 


Billing for different RLT call scenarios 
This section shows how the UCS DMS-250 switches generate billing 
records for the following common call scenarios: 
e ESP redirect and transfer scenario 
e ESP redirect and transfer error scenario 
e third-party interaction scenario 
e third-party interaction error scenario 


e ESP-initiated callback scenario 


The following paragraphs describe the billing for these scenarios and 
provide diagrams that show the specific billing records that each switch 
provides. 


Billing for ESP redirect and transfer scenario 


For details on the redirect and transfer scenario, refer to Chapter 4, 
“Common RLT call scenarios.” In this scenario, the bridging switch 
generates one OSR and CDR pair. However the billing records that an ESP 
generates, if any, depend entirely on the ESP’s specific implementation. 
Each UCS DMS-250 switch other than the bridging switch produces only a 
CDR. Figure 7-1 shows the OSRs and CDRs that UCS DMS-250 switches 
generate for redirect and transfer calls. 
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Figure 7-1 
Billing for ESP redirect and transfer 


(1) Customer originates call; switches route call to services platform 
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Billing for ESP redirect and transfer error scenario 


For details on the redirect and transfer error scenario, refer to Chapter 4, 
“Common RLT call scenarios.” In this scenario, the bridging switch 
generates one CDR for the call’s first leg and another CDR for the second 
leg. Each UCS DMS-250 switch other than the bridging switch produces 
only a CDR. 


Again, the billing records that an ESP generates, if any, depend entirely on 
the ESP’s specific implementation. 


Figure 7-2 shows the OSRs and CDRs that UCS DMS-250 switches 
generate for the redirect and transfer error scenario. 
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Figure 7-2 
Billing for services platform redirect and transfer error scenario 
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Billing for third-party interaction scenario 


For details on the third-party interaction scenario, refer to Chapter 4, 
“Common RLT call scenarios.” In this scenario, the bridging switch 
generates one OSR and CDR pair. Each UCS DMS-250 switch other than 
the bridging switch produces one CDR for the first leg of the call and 
another CDR for the second leg. 


Again, the billing records that an ESP generates, if any, depend entirely on 
the ESP’s specific implementation. 


Figure 7-3 shows the OSRs and CDRs that UCS DMS-250 switches 
generate for the third-party interaction scenario. 
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Figure 7-3 
Billing for third-party interaction scenario 
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Billing for third-party interaction error scenario 


For details on the third-party interaction error scenario, refer to Chapter 4, 
“Common RLT call scenarios.” In this scenario, the bridging switch 
generates one CDR for the call’s first leg and another CDR for the second 
leg. Each UCS DMS-250 switch other than the bridging switch produces one 
CDR for the first leg of the call and another CDR for the second leg. 


Again, the billing records that an ESP generates, if any, depend entirely on 
the ESP’s specific implementation. 


Figure 7-4 shows the OSRs and CDRs that UCS DMS-250 switches 
generate for the third-party interaction scenario. 
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Figure 7-4 
Billing for third—party interaction error scenario 
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Billing for ESP-initiated callback scenario 
For details on the ESP-initiated callback scenario, refer to Chapter 4, 
“Common RLT call scenarios.” In this scenario, the bridging switch 
generates one OSR and CDR pair. Each UCS DMS-250 switch other than 
the bridging switch produces one CDR for the first leg of the call and 
another CDR for the call’s second leg. 


Again, the billing records that an ESP generates, if any, depend entirely on 
the ESP’s specific implementation. 


Figure 7-5 shows the OSRs and CDRs that UCS DMS-250 switches 
generate for the third-party interaction scenario. 
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Figure 7-5 
Billing for ESP-initiated callback scenario 
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Billing for other RLT events 


The following sections describe some of the other RLT events that can affect 
how the UCS DMS-250 switches generate billing records. 


No bridging attempt 
Sometimes, the call’s originator can terminate a call before the services 
platform bridges the call. In such cases, the services platform generates the 
CDR and OSR pair. However, the billing records that an ESP generates, if 
any, depend entirely on the ESP’s specific implementation. 


Charge adjustment for bridged calls 


When an operator adjusts the charge for an RLT call, the services platform 
generates a CDR and OSR pair and an additional OSR. The OSR and CDR 
pair contains complete call information. The other OSR contains charge 
adjustment information only. The bridging switch also generates an OSR 
and CDR pair. This OSR contains both charge adjust information and billing 
information. 


Charge adjustment without bridging 


Sometimes, an operator adjusts the charge for a call that the UCS DMS-250 
switches do not bridge. In such cases, the services platform generates a CDR 
and OSR pair and an additional OSR. The OSR and CDR pair contains 
information about the call to the operator. The other OSR contains only 
charge adjustment information. 


OSR formatter and packaging changes 


Currently, all potential bridging switches with RLT functionality must have 
the current EOPS software installed. To allow elimination of this restriction 
in this release and future releases, one functional change and several 
software packaging changes affect current RLT functionality. 


Note: The UCS12 software release does not support EOPS functionality. 
The UCS software continues to support operator assisted calls through other 
platforms such as the Enhanced Services Provider (ESP). Refer to Appendix 
A in the UCS DMS-250 Feature Change Reference Guide for additional 
information about EOPS removal. 


The functional change involves the use of the table RESTAMA. The OSR 
formatter currently uses this table to modify the service feature digits. If a 
service feature digit is set to FIRM_RESTRICTED (7), the Charge Class 
Screening Code is used to index into table RESTAMA to obtain a new 
service feature digit. If table RESTAMA does not contain datafill, the switch 
sets the service feature digit to 0. The OSR formatter always generates a 
Service Feature digit of 0 if the original service feature digit is set to 
FIRM_RESTRICTED. 
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Common RLT billing scenarios 


This chapter summarizes the flow of Signaling System 7 (SS7) Integrated 
Services Digital Network (ISDN) User Part (ISUP) messages between UCS 
DMS-250 switches and a services platform, such as an Enhanced Services 
Provider (ESP), that supports Release Link Trunk (RLT) capabilities. An 
ESP is a software system that provides specialized switching, billing, and 
call processing features. 


This chapter describes common RLT billing scenarios for the ESP. 


These scenarios describe how UCS DMS-250 switches allow an ESP to do 
the following: 


e determine, on a per-call basis, whether billing duration (CALLDUR in 
the CDR) will begin with the first ANM or the last ANM 


e populate CDR fields BILLNUM, UNIVACC, PINDIGS, and ACCTCD 


External ANM billing control 
As a default the UCS DMS-250 switch starts billing from the first ANM or 
last ANM, as determined by the value of the office parameter 
RLT_FIRST_ANM_BILLING in table OFCVAR. The UCS DMS-250 
switch allows an ESP to override, on a per-call basis, this choice of first- or 
last-ANM billing using a FAR message. The UCS DMS-250 switch allows 
this override once for each call establishment or reorigination. 


The first-/last-ANM billing indicator is optionally included as a field, ANM 
BILLING INDICATOR, in the Operator Information parameter. 
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The following FAR messages appear in this parameter: 
e Bridging FAR 

e Redirection FAR 

e Start billing FAR 

e Cancel billing FAR 


e reorigination FAR 


Populating billing fields 
The UCS DMS-250 switch also allows the ESP to override/update the 
values to be recorded in the CDR fields BILLNUM, UNIVACC, PINDIGS, 
and ACCTCD using the FAR messages and IAMs sent by the ESP. The ESP 
may perform these overrides as many times as required before it releases the 
call. The messages supporting this ability are the following: 


e IAM 

e Bridging FAR 

e Redirection FAR 

e Start billing FAR 

e Cancel billing FAR 
e Reorigination FAR 


Any or all of these parameters may appear in any one FAR message or IAM. 
A FAR message may additionally carry the ANM BILLING INDICATOR 
field in the Operator Information parameter. 


Information received by the ESP during the course of a call may require 
update of the population of the CDR fields BILLNUM, UNIVACC, 
PINDIGS, and/or ACCTCD. Therefore, the UCS DMS-250 switch allows 
the ESP to take control of these billing actions remotely for calls made on 
RLT trunks. 


Message flow summary 


The ANM BILLING INDICATOR may be sent using a FAR message at any 
time up to and including the FAR causing redirection or bridging. An FAA 
message signals that all requests made in that FAR message succeeded; an 
FRJ message signals that the request to which its cause indicator applies did 
not succeed, and that no request in that FAR message of a lower priority 
succeeded. The UCS DMS-250 switch does no create a FAR with the 
first-/last-ANM billing indicator. It only propagates or processes such a FAR 
message received from the ESP. 
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The UCS DMS-250 switch allows multiple requests for actions to be made 
in a single FAR. Table 8-1 lists the priority of these requests for actions. 


Table 8-1 
Priority of FAR requests for action 
Priority Requests 
1 override CDR field values 
2 override 
RLT_FIRST_AMN_BILLING 
3 primary, as specified by the 
facility indicator 


When the UCS DMS-250 switch cannot satisfy all of the requests in a FAR 
message (except the override of CDR values), it returns an FRJ message 
containing a cause indicator. Because this FAR message contains requests 
for additional actions in a single FAR message, the switch could issue a FRJ 
message. This occurs for either of the following reasons: 


e the primary request cannot be performed 


e the first-/last-ANM override has already been performed (which is 
allowed only once per call) 


If a request in a FAR message is rejected, the action it requested is not 
performed, nor is any other action of the same or lower priority. The switch 
does perform actions of a higher priority requested in the same FAR 
message. 


The UCS DMS-250 switch uses possible cause indicator values to 
distinguish why it rejects certain FAR messages. Table 8-2 shows the 
priority of execution of requests in a single FAR message and the 
consequent return of the cause of failure. 


Table 8-2 
Priority of value assignment to FRJ cause indicator 
Priority Request Cause 
1 set first-/last-ANM previous billing 
billing determination 
2 primary request primary request 
rejected 
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The default for each of the fields BILLNUM, UNIVACC, PINDIGS, and 
ACCTCD (that is, when the ESP does not send overriding values in an IAM 
or a FAR message) will be the value populated by the UCS DMS-250 in the 
ordinary course of call setup. The UCS DMS-250 switch performs overrides 
of these CDR field values, but their failure will not cause the switch to 
generate an FRJ message. 


Billing scenarios 


This section provides high-level diagrams and message flow diagrams for 
each of the common RLT call scenarios. Each message flow diagram 
illustrates the SS7 ISUP messaging between a bridging UCS DMS-250 
switch, a remote UCS DMS-250 switch, and a services platform. The 
message flow diagrams highlight parameters that the ISUP messages 
contain. In respect to billing, ESP-initiated calls behave identically to 
bridged calls. Therefore, the additional message flows associated with 
ESP-initiation are not included in the diagrams. For technical descriptions of 
messages and parameters, see Chapter 3, “SS7 ISUP RLT messages and 
protocol.” 


Note: As defined in previous chapters in this manual, the remote switch 
shown in the diagrams can also be the bridging switch under the proper 
conditions. For clarity, however, the bridging and remote switches in this 
chapter’s explanations are not the same switch. Even when the remote 
switch is the bridging switch, each scenario remains essentially the same. 


The scenarios do not explain how a UCS DMS-250 switch generates billing 
records for each RLT call. For billing information, see Chapter 7, “Billing 
for RLT calls.” 

The following RLT call scenarios are common to software the ESP: 

e ESP redirect and transfer 


e third-party interaction 
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ESP redirect and transfer scenario, message flow for bridged and 
redirected calls 


In this scenario, the ESP at the services platform transfers the call to its 
destination and requests release link trunking. After the appropriate switch 
bridges the call, the release link trunking capability frees the services 
platform and the remote UCS DMS-250 switch. 


Note: This scenario is identical to the section entitled “ESP redirect and 
transfer scenario, message flow for bridged and redirected calls” in 
Chapter 4, “Common RLT call scenarios.” 
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Operator or ESP redirect and transfer error scenario, simple 
rejection and recovery 


This section explains the message flow for the redirect and transfer scenario 
when, for whatever reason, a UCS DMS-250 switch cannot perform the 
action requested in the Facility Indicator parameter of a FAR message. In 
this case, the switch involved does not perform the action requested (such as 
release link trunking) and cannot complete the call. The switches must 
process the call using call treatment or other means. 


Message flow for redirect and transfer error scenario 


Figure 8-1 is a comprehensive message flow diagram for the redirect and 
transfer error scenario. It shows the sequence for the exchange of messages 
and parameters between the bridging UCS DMS-250 switch, the remote 
UCS DMS-250 switch, and the services platform. 


Specifically, the message exchange in this error scenario occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. Based on 
the nature of the call, the bridging switch formats an Initial Address 
Message (IAM) and sends it to another switch, the remote switch in this 
scenario. 


2 In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. 


3 The services platform returns an Address Complete Message (ACM) to 
the remote switch. The ACM confirms that the services platform 
received the information needed to route the call to its destination. The 
remote switch passes the ACM to the bridging switch. 


4 When either an ESP at the services platform answers the call, the 
platform sends an Answer Message (ANM) to the remote switch. The 
remote switch formats and sends another ANM to the bridging switch. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 8-3 shows parameters in this 
FAR message that affect RLT functionality. 
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Table 8-3 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 The bridging switch checks a new bridge/redirect FAR message from the 
services platform. The FAR contains the First ANM Billing Indicator 
field set to Last. This switch reads and performs the action designated in 
the FAR message’s Facility Indicator parameter. 


9 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. The FAR contains only 
bridging/redirection information. 
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10 


11 


12 


13 


14 


15 


16 


The bridging switch checks a new bridge/redirect FAR message from the 
services platform. The FAR contains the Operator Information parameter 
that contains the first/last ANM Billing Indicator field set to first. This 
switch reads and tries to perform the action designated in the FAR 
message’s Facility Indicator parameter. 


The switch that attempted bridging returns a Facility Reject (FRJ) 
message to the remote switch to indicate that it could not perform the 
facility request. This message’s Cause Indicator parameter contains a 
Previous Billing Determination value. In this scenario, the switch cannot 
perform the action because the first/last Billing Indicator can only be set 
to a new value once. In this scenario, because this request has a higher 
priority than the primary request, the switch does not execute the 
primary request and rejects the FAR. 


The bridging switch checks a new bridge/redirect FAR message from the 
services platform. The FAR contains only bridging/redirection 
information. This switch reads and tries to perform the action designated 
in the FAR message’s Facility Indicator parameter. In this scenario, the 
switch bridges the call. 


To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. The FAR contains only 
bridging/redirection information. 


After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. 
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Figure 8-1 
Message flow for redirect and transfer error scenario 
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Figure 8-1 
Message flow for redirect and transfer error scenario (continued) 


Services platform 


Bridging Remote 
switch switch 


Facility Indicator 
Call Reference 


Facility Indicator 
Call Reference 


Facility Indicator 
a : Called Party Number 
Facility Indicator j 
Called Party Number Calling Party Number 


; Generic Digits 
Calling Party Number Operator Information 
Generic Digits 


Operator Information 


Facility Indicator 
Cause Indicator 


Facility Indicator 
Cause Indicator 


Legend: Parameters 
Bold = Mandatory Regular = Optional 


Italics =Required for RLT functionality 


—continued— 


297-2621-345 Standard 04.02 November 1999 


Common RLT billing scenarios 8-11 


Figure 8-1 
Message flow for redirect and transfer error scenario (continued) 
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ESP redirect and transfer scenario, billing setup and update using a 
FAR message 


In this scenario, the ESP at the services platform transfers the call to its 
destination and requests release link trunking. After the appropriate switch 
bridges the call, the release link trunking capability frees the services 
platform and the remote switch. 


The trunks connecting the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and each services platform is an ISUP intermachine trunk 
(IMT) with RLT functionality. The trunk connecting the caller to the 
bridging switch is one of the following: 


e aper-trunk signaling (PTS) trunk 

e aprimary rate interface (PRI) trunk 

e an ISUP FGD trunk 

e an ISUP IMT without RLT functionality 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 


Message flow for redirect and transfer scenario 


Figure 8-2 is a comprehensive message flow diagram for the redirect and 

transfer scenario. It shows the sequence for the exchange of messages and 
parameters between the bridging UCS DMS-250 switch, the remote UCS 

DMS-250 switch, and the services platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. Based on 
the nature of the call, the bridging switch formats an Initial Address 
Message (IAM) and sends it to another switch, the remote switch in this 
scenario. 


Note: The CDR fields BILLNUM, UNIVACC, PINDIGS, and 
ACCTCD are initially populated by call setup. 


2 In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. 


3 The services platform returns an Address Complete Message (ACM) to 
the remote switch. The ACM confirms that the services platform 
received the information needed to route the call to its destination. The 
remote switch passes the ACM to the bridging switch. 
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4 When the services platform answers the call, the platform sends an 
Answer Message (ANM) to the remote switch. The remote switch 
formats and sends another ANM to the bridging switch. 


5 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 8-4 shows parameters in this 
FAR message that affect RLT functionality. 


Table 8-4 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


Generic Digits This parameter contains values for the following 
fields: 
e BILLNUM, value from first FAR 
e UNIVACC, value from first FAR 
e PINDIGS, value from first FAR 
e ACCTCD, value from first FAR 


Operator Information Contains ANM Billing indicator set to either first or 
last. 


6 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


7 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 
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Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
UCS DMS-250 switch connects to another switch across a trunk that 
does not support RLT functionality. That switch reads the FAR 
message’s Facility Indicator parameter and performs the function that the 
parameter designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


8 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. 


9 The services platform identifies the called party, but does not make the 
call to that party. It sends another Facility Request (FAR) message to the 
remote switch. Table 8-5 shows parameters in this FAR message that 
affect RLT functionality. 


Table 8-5 
RLT parameters in the billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


Generic Digits This parameter contains values for the following 
fields: 
e BILLNUM, value from second FAR 
e UNIVACC, value from second FAR 
e PINDIGS, value from second FAR 
e ACCTCD, value from second FAR 


10 The remote UCS DMS-250 switch checks the FAR message and 
determines that the trunk connecting the bridging switch and the remote 
switch supports RLT functionality. The remote switch then passes the 
FAR message to the bridging switch. 
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11 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


12 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. 


13 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 8-6 shows parameters in this 
FAR message that affect RLT functionality. 


Table 8-6 
RLT parameters in the Redirect FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. This parameter also 
contains the first/last ANM billing indicator. 


—continued— 
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Table 8-6 
RLT parameters in the Redirect FAR message (continued) 


RLT parameter Comments 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
fields: 


e BILLNUM, value from second FAR 
e UNIVACC, value from second FAR 
e PINDIGS, value from second FAR 
e ACCTCD, value from third FAR 


—end— 


14 The remote switch passes the FAR to the bridging switch. Because the 
trunk connecting the bridging switch to the switch from which it 
originally received the call does not support RLT functionality, it reads 
the message’s Facility Indicator and performs release link trunking. 
Using translations of the Called Party Number parameter, the bridging 
switch completes the second leg of the call. 


15 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. 


16 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 
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17 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


18 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. 
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Figure 8-2 
Message flow for redirect and transfer scenario 
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Figure 8-2 
Message flow for redirect and transfer scenario (continued) 
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Figure 8-2 
Message flow for redirect and transfer scenario (continued) 
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ESP redirect and transfer error scenario, FAR message failure and 


reissue 


This section explains the message flow for the redirect and transfer scenario 
when, for whatever reason, a UCS DMS-250 switch cannot perform the 
action requested in the Facility Indicator parameter of a FAR message. In 
this case, the switch involved does not perform the action requested (such as 
release link trunking) and cannot complete the call. The switches must 
process the call using call treatment or other means. The error scenario is 
identical to the standard redirect and transfer scenario up to step 7. 


Message flow for redirect and transfer error scenario 


Figure 8-3 is a comprehensive message flow diagram for the redirect and 
transfer error scenario. It shows the sequence for the exchange of messages 
and parameters between the bridging UCS DMS-250 switch, the remote 
UCS DMS-250 switch, and the services platform. 


Specifically, the message exchange in this error scenario occurs as follows: 


1 A switch, the bridging switch in this scenario, receives the call. The 
switches and services platform exchange messages just as in steps 1-4 in 
the standard redirect and transfer scenario. 


2 The services platform identifies the called party, but does not make the 
call to that party. First, it initiates billing by sending a Facility Request 
(FAR) message to the remote switch. Table 8-7 shows parameters in this 
FAR message that affect RLT functionality. 
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Table 8-7 
RLT parameters in the billing FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


Generic Digits This parameter contains values for the following 
fields: 
e BILLNUM, value from first FAR 
e UNIVACC, value from first FAR 
e PINDIGS, value from first FAR 
e ACCTCD, value from first FAR 


Operator Information Contains ANM Billing indicator set to first. 


3 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


4 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


5 To acknowledge that it received and processed the FAR message, the 
bridging switch formats a Facility Accept (FAA) message and sends it to 
the remote switch, which passes it to the services platform. 


6 The bridging switch checks a new bridge/redirect FAR message from the 
services platform. The FAR contains the ANM Billing Indicator field set 
to last. This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. Table 8-8 shows parameters in 
this FAR message that affect RLT functionality. 
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Table 8-8 
RLT parameters in the bridge/redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


Generic Digits This parameter contains values for the following 
fields: 
e BILLNUM, value from first FAR 
e UNIVACC, value from first FAR 
e PINDIGS, value from first FAR 
e ACCTCD, value from first FAR 


Operator Information Contains ANM Billing indicator set to first. 


7 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. The FAR contains only 
bridging/redirection information. 


8 The bridging switch checks a new bridge/redirect FAR message from the 
services platform. This switch reads and tries to perform the action 
designated in the FAR message’s Facility Indicator parameter. In this 
scenario, the switch cannot perform the action because the first/last 
Billing Indicator can only be set to a new value once. Table 8-9 shows 
parameters in this FAR message that affect RLT functionality. 
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Table 8-9 
RLT parameters in the Redirect FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. This parameter also 
contains the first/last ANM billing indicator. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
fields: 


e BILLNUM, value from second FAR 
e UNIVACC, value from second FAR 


PINDIGS, value from second FAR 
ACCTCD, value from fourth FAR 
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9 The switch that attempted bridging returns a Facility Reject (FRJ) 
message to the remote switch to indicate that it could not perform the 
facility request. This message’s Cause Indicator parameter contains a 
Previous Billing Determination value. In this scenario, the switch cannot 
perform the action because the first/last Billing Indicator can only be set 
to a new value once. In this scenario, because this request has a higher 
priority than the primary request, the switch does not execute the 
primary request and rejects the FAR. 


10 The bridging switch checks a new bridge/redirect FAR message from the 
services platform. The FAR contains only bridging/redirection 
information. This switch reads and tries to perform the action designated 
in the FAR message’s Facility Indicator parameter. In this scenario, the 
switch bridges the call. Table 8-10 shows parameters in this FAR 
message that affect RLT functionality. 


Table 8-10 
RLT parameters in the Redirect FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for Operator Redirect/Transfer value 
that the bridging switch uses. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. This parameter also 
contains the first/last ANM billing indicator. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


—continued— 
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Table 8-10 
RLT parameters in the Redirect FAR message (continued) 
RLT parameter Comments 
Called Party Number The remote switch copies the value of this 


parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
fields: 


e BILLNUM, value from second FAR 
e UNIVACC, value from second FAR 


e PINDIGS, value from second FAR 
e ACCTCD, value from third FAR 


—end— 


11 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. The FAR contains only 
bridging/redirection information. 


12 After bridging the call, the bridging switch formats a Release (REL) 
message and sends it to the remote switch. The REL message includes a 
Normal Clearing Cause Indicator parameter. 


13 The remote switch sends another REL message to the services platform 
and releases the connection to the services platform and the 
corresponding trunks. It also sends a Release Complete (RLC) message 
back to the bridging switch to confirm the release. This RLC also 
includes a proper Cause Indicator parameter. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 
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14 The services platform also releases its connections and returns another 
RLC with a proper Cause Indicator to the remote switch to confirm the 
release. 
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Figure 8-3 
Message flow for redirect and transfer error scenario 
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Figure 8-3 
Message flow for redirect and transfer error scenario (continued) 
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Figure 8-3 
Message flow for redirect and transfer error scenario (continued) 
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Third-party interaction scenario, billing setup using an IAM, update 
using a FAR message 


In this scenario, a customer places a call to the ESP and requests the ESP to 
establish a three-way call. When the parties are in conference, the ESP 
requests release link trunking. After the appropriate switch bridges the call, 
the release link trunking capability frees the ESP and the remote UCS 
DMS-250 switch. 


The trunks connecting the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the services platform are all ISUP IMTs with RLT 
functionality. The trunk connecting the caller to the bridging switch is one of 
the following: 


e aPTS trunk 

e aPRI trunk 

e an ISUP FGD trunk 

e an ISUP IMT without RLT functionality 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Calls involving a third party, such as an ESP, are each logically two calls 
from th point of view of the switch, each having its own billing information. 
When these two logical legs are bridged, the respective sets of billing 
information must be merged into one. When the switch merges billing fields, 
it takes the values from the following call legs as shown in Table 8-11. 


Table 8-11 
Billing merge values 
Billing field Value from 
BILLNUM first call leg; if not available, second 
call leg 
UNIVACC first call leg 
PINDIGS second call leg; if not available, first 
call leg 
ACCTCD second call leg; if not available, first 
call leg 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 
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Message flow for third-party interaction 
Figure 8-4 is a comprehensive message flow diagram for the third-party 
interaction scenario. It shows the sequence for the exchange of messages 
between the bridging UCS DMS-250 switch, the remote UCS DMS-250 
switch, and the services platform. 


Specifically, the message exchange occurs as follows: 


1 


A switch, the bridging switch in this scenario, receives a call. Based on 
the nature of the call, the bridging switch formats an IAM and sends it to 
another switch, the remote switch in this scenario. 


Note: If the call is an NOO services call, the switch performs NOO lookup 
(that is, it translates the NOO services call into a ten-digit number). The 
switch places the NOO number into the CDRs Dialed Number field and 
places the ten-digit number into the CDR’s Called Number field. 


Note: The CDR fields BILLNUM, UNIVACC, PINDIGS, and 
ACCTCD are initially populated by call setup. 


2 In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 8-12 shows the 
important RLT parameters in this IAM. 

Table 8-12 


RLT parameters in the first leg IAM 


RLT parameter Comments 


Called Party Number The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


Charge Number This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


—continued— 
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Table 8-12 
RLT parameters in the first leg IAM (continued) 
RLT parameter Comments 
Calling Party Number This parameter contains an ANI value. The 


switches add this ANI value to the ANI SPILL field 
in the call’s CDR, unless they pull the ANI value 
from the Charge Number parameter. 


Generic Digits This parameter contains values for the following 
CDR fields: 
e BILLNUM 
e UNIVACC 
e PINDIGS 
e ACCTCD 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(see Chapter 5, RLT call scenarios for ESP, for a 
description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLTO002). 


—end— 


3 The services platform returns an ACM to the remote switch. The ACM 
confirms that the services platform received the information needed to 
route the call to its destination. The remote switch passes the ACM to the 
bridging switch. 


4 When the services platform answers the call, the platform sends an ANM 
to the remote switch. The remote switch formats and sends another 
ANM to the bridging switch. 


5 The services platform identifies the called party and initiates the second 
leg of the call, formatting a new IAM and sending it to the remote 
switch. Because the trunk connecting the remote switch and the services 
platform supports RLT functionality, the [AM includes the 
Supplementary Line Information (SLI) parameter. Table 8-13 shows 
parameters in this IAM that affect RLT functionality. 
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Table 8-13 


RLT parameters in the second leg IAM 


RLT parameter 


Called Party Number 


Charge Number 


Calling Party Number 


Supplementary Line 
Information (SLI) 


Transit Network 
Selector 


Comments 


The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


This parameter contains an ANI value. The 
switches add this ANI value to the ANI SPILL field 
in the call’s CDR, unless they pull the ANI value 
from the Charge Number parameter. 


This parameter causes a receiving switch to 
include a Call Reference parameter in an ACM 
when it responds. In this scenario, this parameter 
has an “RLT Call Operation” value. 


This parameter’s Reorigination Call field identifies 
whether the call is a boomerang reorigination call 
(see Chapter 5, RLT call scenarios for ESP, for a 

description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


6 When it receives the IAM, the remote switch formats another IAM and 
sends it to the bridging switch. Because the trunk connecting the remote 


switch and the bridging switch supports RLT functionality, this IAM also 


includes the SLI parameter. 


7 Inresponse to the IAM with the SLI parameter, the bridging switch 
returns an ACM with a Call Reference parameter that identifies the 
second leg of the call. This ACM indicates that the terminating switch 
received the information that it needs to route the call. 
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8 The remote switch copies and saves the Call Reference parameter from 
the ACM. Then it changes the Call Reference in the ACM to contain the 
Call Reference information for the second leg of the call. The switch 
routes this ACM to the services platform, which also saves the Call 
Reference parameter. 


9 When the terminating party of the second leg answers, the bridging 
switch formats an ANM and sends it to the remote switch. The remote 
switch passes the ANM to the services platform, connecting it in a 
three-way call with the calling party and called party. 


10 The services platform initiates billing by sending a FAR message to the 
remote switch. Table 8-14 shows parameters in this FAR message that 
affect RLT functionality. 


Table 8-14 
RLT parameters in the Billing FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the specific action that the 
FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


Operator Information This parameter contains the ANM Billing Indicator 
set to either first or last. 


11 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


12 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 
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Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


13 To acknowledge that it received and processed the FAR message, the 
bridging switch formats an FAA message and sends it to the remote 
switch, which passes it to the services platform. 


14 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. Table 8-15 shows parameters in this FAR message 
that affect RLT functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have Call Reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 


Table 8-15 


RLT parameters in the third-party FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the action that the FAR 
message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


—continued— 
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Table 8-15 


RLT parameters in the third-party FAR message (continued) 


RLT parameter 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


Note: As each intermediate tandem switch 
passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s CDR and includes it in 
the call’s OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from call setup 

e UNIVACC, value from call setup 

e PINDIGS, value from IAM 

e ACCTCD, value from second FAR 


—end— 


15 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


8-38 Common RLT billing scenarios 


16 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch (see step 8). The remote switch adds this Call 
Reference information to a FAR message and sends the message to the 
bridging switch. 


17 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 


18 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. 


19 After bridging the call, the bridging switch formats two REL messages 
and sends them to the remote switch to release the call connections for 
both call legs. The REL messages include Normal Clearing Cause 
Indicator parameters. 


20 The remote switch sends two REL messages to the services platform and 
releases the call connections to the services platform and the 
corresponding trunks. It also sends two RLC messages back to the 
bridging switch to confirm the release of the first and second call legs. 
The RLC’s also include proper Cause Indicator parameters. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


21 The services platform also releases its connections and returns two 
RLC’s with proper Cause Indicator parameters to the remote switch to 
confirm the release of both call legs. 
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Figure 8-4 
Message flow for third-party interaction scenario 
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Figure 8-4 


Message flow for third-party interaction scenario (continued) 
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Figure 8-4 
Message flow for third-party interaction scenario (continued) 
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Figure 8-4 
Message flow for third-party interaction (continued) 
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Third-party interaction error scenario, failure to update, 

update on bridging 
This section explains the message flow for the third-party interaction 
scenario when, for whatever reason, a UCS DMS-250 switch or 
interconnecting trunk cannot perform the action requested in the Facility 
Indicator parameter of a FAR message. In this case, the switch involved does 
not perform the action requested (such as release link trunking), but may 
complete the call, depending on conditions. The error scenario is identical to 
the standard third-party interaction scenario up to step 9. 


Message flow for third-party interaction error scenario 


Figure 8-5 is a comprehensive message flow diagram for the third-party 
interaction error scenario. It shows the sequence for the exchange of 
messages between the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the services platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the bridging switch in this scenario, receives a call. The 
switches and services platform exchange messages just as in steps 1-9 in 
the standard third-party interaction error scenario. 


2 The services platform initiates billing by sending a FAR message to the 
remote switch. Table 8-16 shows parameters in this FAR message that 
affect RLT functionality. 
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Table 8-16 
RLT parameters in the Billing FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 


uses. 

Operator Information This parameter contains the ANM Billing Indicator 
set to last. 

Generic Digits This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from call setup 
e UNIVACC, value from call setup 
e PINDIGS, value from call setup 
e ACCTCD, value from first FAR 


3 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


4 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 
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Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


5 To acknowledge that it received and processed the FAR message, the 
bridging switch formats an FAA message and sends it to the remote 
switch, which passes it to the services platform. 


6 The ESP initiates release link trunking, sending another FAR message to 
the remote switch. Table 8-17 shows parameters in this FAR message 
that affect RLT functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have Call Reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 


Table 8-17 
RLT parameters in the third-party FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the action that the FAR 
message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem switch 
passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


—continued— 
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Table 8-17 
RLT parameters in the third-party FAR message (continued) 


RLT parameter Comments 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from second FAR 
e UNIVACC, value from call setup 

e PINDIGS, value from call setup 

e ACCTCD, value from first FAR 


—end— 


7 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


8 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch. The remote switch adds this Call Reference 
information to a FAR message and sends the message to the bridging 
switch. 
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9 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 

Table 8-18 shows parameters in this FAR message that affect RLT 
functionality. 


Table 8-18 
RLT parameters in the billing second-leg third-party FAR message 


RLT parameter Comments 
Generic Digits This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from IAM 
e UNIVACC, value from IAM 
e PINDIGS, value from IAM 
e ACCTCD, value from second FAR 


10 The switch that attempted bridging returns a Facility Reject (FRJ) 
message to the remote switch to indicate that it could not perform the 
facility request. This message’s Cause Indicator parameter contains a 
Previous Billing Determination value. In this scenario, the switch cannot 
perform the action because the first/last Billing Indicator can only be set 
to a new value once. In this scenario, because this request has a higher 
priority than the primary request, the switch does not execute the 
primary request and rejects the FAR. 


11 The operator or ESP at the services platform initiates release link 
trunking, sending another FAR message to the remote switch. Table 8-19 
shows parameters in this FAR message that affect RLT functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have Call Reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 
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Table 8-19 
RLT parameters in the third-party FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the action that the FAR 


message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party interaction Call value 
that the bridging switch uses. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem 

switch passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


Calling Party Number The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s CDR and includes it in 
the call’s OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains values for the following 
CDR fields merged from both call legs: 


e BILLNUM, value from second FAR 
e UNIVACC, value from call setup 
PINDIGS, value from IAM 
ACCTCD, value from third FAR 
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12 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


13 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch. The remote switch adds this Call Reference 
information to a FAR message and sends the message to the bridging 
switch. 


14 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 


15 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. 


16 After bridging the call, the bridging switch formats two REL messages 
and sends them to the remote switch to release the call connections for 
both call legs. The REL messages include Normal Clearing Cause 
Indicator parameters. 


17 The remote switch sends two REL messages to the services platform and 
releases the call connections to the services platform and the 
corresponding trunks. It also sends two RLC messages back to the 
bridging switch to confirm the release of the first and second call legs. 
The RLC’s also include proper Cause Indicator parameters. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


18 The services platform also releases its connections and returns two 
RLC’s with proper Cause Indicator parameters to the remote switch to 
confirm the release of both call legs. 
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Figure 8-5 
Message flow for third-party interaction error scenario 
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Figure 8-5 
Message flow for third-party interaction erro 
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Figure 8-5 
Message flow for third-party interaction error scenario (continued) 
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Figure 8-5 
Message flow for third-party interaction error scenario (continued) 


Services platform 


Bridging Remote 


Facility Indicator 
Call Reference 


Legend: Parameters 
Bold = Mandatory Regular = Optional 
Italics =Required for RLT functionality 


—continued— 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


8-54 Common RLT billing scenarios 


Figure 8-5 
Message flow for third-party interaction error scenario (continued) 


Servicesplatform 


Bridging Remote 
switch switch 


Release link trunking for second call leg 
REL 


Cause Indicator 


Cause Indicator 
Cause Indicator 


Cause Indicator 


Legend: Parameters 
Bold = Mandatory Regular = Optional 


Italics =Required for RLT functionality 


—end— 


297-2621-345 Standard 04.02 November 1999 


Common RLT billing scenarios 8-55 


Third-party interaction scenario, successful update 
In this scenario, a customer makes a call that requires the ESP to place the 
three-way call. When the parties are in conference, the ESP requests release 
link trunking. After the appropriate switch bridges the call, the release link 


trunking capability frees the services platform and the remote UCS 
DMS-250 switch. 


The trunks connecting the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the services platform are all ISUP IMTs with RLT 
functionality. The trunk connecting the caller to the bridging switch is one of 
the following: 


e aPTS trunk 

e aPRI trunk 

e an ISUP FGD trunk 

e an ISUP IMT without RLT functionality 


By definition, a switch only bridges a call when it cannot remove itself from 
the connection by passing the bridge request to another switch. 


Calls involving a third party, such as an ESP, are each logically two calls 
from the point of view of the switch, each having its own billing 
information. When these two logical legs are bridged, the respective sets of 
billing information must be merged into one. When the switch merges 
billing fields, it takes the values from the following call legs as shown in 


Table 8-20. 
Table 8-20 
Billing merge values 
Billing field Value from 
BILLNUM first call leg; if not available, second 
call leg 
UNIVACC first call leg 
PINDIGS second call leg; if not available, first 
call leg 
ACCTCD second call leg; if not available, first 
call leg 


Note: PRI trunks and ISUP IMTs do not support call reorigination. 
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Message flow for third-party interaction 


Figure 8-6 is a comprehensive message flow diagram for the third-party 
interaction scenario. It shows the sequence for the exchange of messages 
between the bridging UCS DMS-250 switch, the remote UCS DMS-250 
switch, and the services platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the bridging switch in this scenario, receives a call. Based on 


the nature of the call, the bridging switch formats an IAM and sends it to 


another switch, the remote switch in this scenario. 


Note: The CDR fields BILLNUM, UNIVACC, PINDIGS, and 
ACCTCD are initially populated by call setup. 


2 In response to the IAM from the bridging switch, the remote switch 
sends another IAM to the services platform. Table 8-21 shows 
parameters in this IAM that affect RLT functionality. 


Table 8-21 


RLT parameters in the first leg IAM 


RLT parameter 


Called Party Number 


Charge Number 


Calling Party Number 


Comments 


The switches use the number of the party called 
when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


This parameter contains an ANI value. The 
switches add this ANI value to the ANI SPILL field 
in the call’s CDR, unless they pull the ANI value 
from the Charge Number parameter. 


—continued— 
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Table 8-21 
RLT parameters in the first leg IAM (continued) 
RLT parameter Comments 
Generic Digits This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from IAM 
e UNIVACC, value from IAM 
e PINDIGS, value from IAM 
e ACCTCD, value from IAM 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(see Chapter 5, RLT call scenarios for ESP, for a 
description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


—end— 


3 The services platform returns an ACM to the remote switch. The ACM 
confirms that the services platform received the information needed to 
route the call to its destination. The remote switch passes the ACM to the 
bridging switch. 


4 When the services platform answers the call, the platform sends an ANM 
to the remote switch. The remote switch formats and sends another 
ANM to the bridging switch. 


5 The services platform identifies the called party and initiates the second 
leg of the call, formatting a new IAM and sending it to the remote 
switch. Because the trunk connecting the remote switch and the services 
platform supports RLT functionality, the IAM includes the 
Supplementary Line Information (SLI) parameter. Table 8-22 shows 
parameters in this IAM that affect RLT functionality. 
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Table 8-22 
RLT parameters in the second leg IAM 
RLT parameter Comments 
Called Party Number The switches use the number of the party called 


when generating billing records. The switches 
place this value in the Called Number field of the 
CDR for the call. 


This parameter also provides an NOA value that 
indicates whether the call is operator-assisted or 
whether the switch must treat the call. 


Charge Number This parameter contains an ANI value. If the IAM 
contains this parameter, the switches add this 
value to the ANI SPILL field in the call’s CDR. If 
the IAM does not contain this parameter, the 
switches get the ANI value from the Calling Party 
Number parameter. 


Calling Party Number This parameter contains an ANI value. The 
switches add this ANI value to the ANI SPILL field 
in the call’s CDR, unless they pull the ANI value 
from the Charge Number parameter. 


Generic Digits This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from IAM 
e UNIVACC, value from IAM 
e PINDIGS, value from IAM 
e ACCTCD, value from IAM 


—continued— 
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Table 8-22 

RLT parameters in the second leg IAM (continued) 
RLT parameter Commenis 
Supplementary Line This parameter causes a receiving switch to 
Information (SLI) include a Call Reference parameter in an ACM 


when it responds. In this scenario, this parameter 
has an RLT Call Operation value. 


Transit Network This parameter’s Reorigination Call field identifies 

Selector whether the call is a boomerang reorigination call 
(see Chapter 5, RLT call scenarios for ESP, for a 
description of boomerang reorigination). 


Note: The Transit Network Selector parameter 
includes the Reorigination Call field only in IAMs, 
and only when the switch has the Enhanced 
Reorigination for Operator Services feature 
(URLT0002). 


—end— 


6 When it receives the IAM, the remote switch formats another IAM and 
sends it to the bridging switch. Because the trunk connecting the remote 
switch and the bridging switch supports RLT functionality, this IAM also 
includes the SLI parameter. 


7 Inresponse to the IAM with the SLI parameter, the bridging switch 
returns an ACM with a Call Reference parameter that identifies the 
second leg of the call. This ACM indicates that the terminating switch 
received the information that it needs to route the call. 


8 The remote switch copies and saves the Call Reference parameter from 
the ACM. Then it changes the Call Reference in the ACM to contain the 
Call Reference information for the second leg of the call. The switch 
routes this ACM to the services platform, which also saves the Call 
Reference parameter. 


9 When the terminating party of the second leg answers, the bridging 
switch formats an ANM and sends it to the remote switch. The remote 
switch passes the ANM to the services platform, connecting it in a 
three-way call with the calling party and called party. 


10 The services platform initiates billing by sending a FAR message to the 
remote switch. Table 8-23 shows parameters in this FAR message that 
affect RLT functionality. 
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Table 8-23 
RLT parameters in the Billing FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


11 


12 


Generic Digits This parameter contains values for the following 


Operator Information This parameter contains the ANM Billing Indicator 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 
uses. 


CDR fields: 

e BILLNUM, value from first FAR 

e UNIVACC, value from call setup 
e PINDIGS, value from call setup 
e ACCTCD, value from call setup 


set to either first or last. 


The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 
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Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


13 To acknowledge that it received and processed the FAR message, the 
bridging switch formats an FAA message and sends it to the remote 
switch, which passes it to the services platform. 


14 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 8-24 shows parameters in this 
FAR message that affect RLT functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have Call Reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 


Table 8-24 
RLT parameters in the third-party FAR message 


RLT parameter Comments 


Facility Indicator This parameter defines the action that the FAR 
message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem switch 
passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


—continued— 
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Table 8-24 
RLT parameters in the third-party FAR message (continued) 


RLT parameter Comments 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


Called Party Number The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from first FAR 

e UNIVACC, value from call setup 

e PINDIGS, value from IAM 

e ACCTCD, value from second FAR 


—end— 


15 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


16 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch (see step 8). The remote switch adds this Call 
Reference information to a FAR message and sends the message to the 
bridging switch. 
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17 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 


18 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. 


19 After bridging the call, the bridging switch formats two REL messages 
and sends them to the remote switch to release the call connections for 
both call legs. The REL messages include Normal Clearing Cause 
Indicator parameters. 


20 The remote switch sends two REL messages to the services platform and 
releases the call connections to the services platform and the 
corresponding trunks. It also sends two RLC messages back to the 
bridging switch to confirm the release of the first and second call legs. 
The RLC’s also include proper Cause Indicator parameters. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


21 The services platform also releases its connections and returns two 
RLC’s with proper Cause Indicator parameters to the remote switch to 
confirm the release of both call legs. 
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Figure 8-6 
Message flow for third-party interaction scenario 
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Figure 8-6 
Message flow for third-party interaction scenario (continued) 
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Figure 8-6 
Message flow for third-party interaction scenario (continued) 
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Figure 8-6 
Message flow for third-party interaction (continued) 
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Third-party interaction error scenario, bridging failure 


This section explains the message flow for the third-party interaction 
scenario when, for whatever reason, a UCS DMS-250 switch or 
interconnecting trunk cannot perform the action requested in the Facility 
Indicator parameter of a FAR message. In this case, the switch involved does 
not perform the action requested (such as release link trunking), but may 
complete the call, depending on conditions. The error scenario is identical to 
the standard third-party interaction scenario up to step 9. 


Message flow for third-party interaction error scenario 


Figure 8-7 is a comprehensive message flow diagram for the third-party 
interaction error scenario. It shows the sequence for the exchange of 
messages between the bridging UCS DMS-250 switch, the remote UCS 
DMS-250 switch, and the services platform. 


Specifically, the message exchange occurs as follows: 


1 A switch, the bridging switch in this scenario, receives a call. The 
switches and services platform exchange messages just as in steps 1—9 in 
the standard third-party interaction scenario. 


2 The services platform initiates billing by sending a FAR message to the 
remote switch. Table 8-25 shows parameters in this FAR message that 
affect RLT functionality. 


Table 8-25 
RLT parameters in the Billing FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the specific action that the 


FAR message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Start Billing Time value that the bridging switch 


uses. 

Operator Information This parameter contains the ANM Billing Indicator 
set to last. 

Generic Digits This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from first FAR 
e UNIVACC, value from call setup 
e PINDIGS, value from call setup 


e ACCTCD, value from call setup 
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3 The remote switch checks the FAR message and determines that the 
trunk connecting the bridging switch and the remote switch supports 
RLT functionality. The remote switch then passes the FAR message to 
the bridging switch. 


4 The bridging switch also checks the FAR message. It determines that the 
trunk that connects it to the switch from which it originally received the 
call is either a PTS trunk or an ISUP trunk that does not support RLT. 
This switch reads and performs the action designated in the FAR 
message’s Facility Indicator parameter. In this scenario, the indicator 
starts billing. 


Note 1: In this example, the services platform, remote, and bridging 
switches are the only switches in the scenario. In real cases, however, the 
scenario could involve a line of many switches. Each switch in the line 
checks whether the trunk connecting it to the switch from which it 
originally received a call supports RLT functionality. If so, it passes the 
FAR message to that switch. At some point in the line of switches, a 
switch connects to another switch across a trunk that does not support 
RLT functionality. That switch reads the FAR message’s Facility 
Indicator parameter and performs the function that the parameter 
designates. 


Note 2: For the same reason, if the trunk between the bridging switch 
and the remote switch in this scenario did not support release link 
trunking, the remote switch would not pass the FAR message, and would 
therefore be the bridging switch. 


5 To acknowledge that it received and processed the FAR message, the 
bridging switch formats an FAA message and sends it to the remote 
switch, which passes it to the services platform. 


6 The services platform sends another FAR message to the remote switch. 
This FAR message contains the ANM Billing Indicator set to first in the 
Operator Information parameter. Table 8-26 shows parameters in this 
FAR message that affect RLT functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have Call Reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 
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Table 8-26 
RLT parameters in the first-leg third-party FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the action that the FAR 


message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem switch 
passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


Calling Party Number The switches, except the bridging switches, copy 
the value of this parameter to the CALLING 
NUMBER field in the OSR for the call. If the FAR 
message does not include the Calling Party 
Number parameter, the switch obtains billing 
information from the call’s CDR and includes it in 
the call’s OSR. 


—continued— 
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Table 8-26 

RLT parameters in the first-leg third-party FAR message (continued) 
RLT parameter Commenis 
Called Party Number The remote switch copies the value of this 


parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
service platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from first FAR 
e UNIVACC, value from second FAR 
e PINDIGS, value from call setup 
e ACCTCD, value from call setup 


—end— 


7 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


8 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch. The remote switch adds this Call Reference 
information to a FAR message and sends the message to the bridging 
switch. 


9 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 

Table 8-27 shows parameters in this FAR message that affect RLT 
functionality. 
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Table 8-27 
RLT parameters in the billing second-leg third-party FAR message 


RLT parameter Comments 
Generic Digits This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from IAM 
e UNIVACC, value from IAM 
e PINDIGS, value from second FAR 
e ACCTCD, value from second FAR 


10 The UCS DMS-250 switch that attempted bridging returns a Facility 


11 


Reject (FRJ) message to the remote switch to indicate that it could not 
perform the facility request. This message’s Cause Indicator parameter 
contains a Previous Billing Determination value. In this scenario, the 
switch cannot perform the action because the first/last Billing Indicator 
can only be set to a new value once. In this scenario, because this request 
has a higher priority than the primary request, the switch does not 
execute the primary request and rejects the FAR. 


The services platform sends another FAR message to the remote switch. 
Table 8-28 shows parameters in this FAR message that affect RLT 
functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have Call Reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 
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Table 8-28 
RLT parameters in the third-party FAR message 
RLT parameter Comments 
Facility Indicator This parameter defines the action that the FAR 


message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


Call Reference This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem 

switch passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


Operator Information This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


Calling Party Number The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the call’s 
OSR. 


—continued— 
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Table 8-28 
RLT parameters in the third-party FAR message (continued) 
RLT parameter Comments 
Called Party Number The remote switch copies the value of this 


parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


Generic Digits This parameter contains the CALLID value that the 
services platform provided. The bridging switch 
places this value in the CALLID field in the OSR 
for the call and uses the value to match OSRs on 
both the services platform and bridging switches. 
This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from first FAR 
e UNIVACC, value from second FAR 
e PINDIGS, value from call setup 
e ACCTCD, value from third FAR 


—end— 


12 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


13 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch. The remote switch adds this Call Reference 
information to a FAR message and sends the message to the bridging 
switch. 


14 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 

Table 8-29 shows parameters in this FAR message that affect RLT 
functionality. 
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Table 8-29 
RLT parameters in the billing second-leg third-party FAR message 


RLT parameter Comments 
Generic Digits This parameter contains values for the following 
CDR fields: 


e BILLNUM, value from IAM 
e UNIVACC, value from IAM 
e PINDIGS, value from second FAR 
e ACCTCD, value from second FAR 


15 The switch that attempted bridging returns a Facility Reject (FRJ) 
message to the remote switch to indicate that it could not perform the 
facility request. This message’s Cause Indicator parameter contains a 
Previous Billing Determination value. In this scenario, the switch cannot 
perform the action because the first/last Billing Indicator can only be set 
to a new value once. In this scenario, because this request has a higher 
priority than the primary request, the switch does not execute the 
primary request and rejects the FAR. 


16 The services platform initiates release link trunking, sending another 
FAR message to the remote switch. Table 8-30 shows parameters in this 
FAR message that affect RLT functionality. 


Note: A services platform or switch always sends a FAR message to the 
trunk circuit of the leg for which it does not have Call Reference 
information. In this scenario, the services platform sends the FAR 
message to the trunk of the call’s first leg. 
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Table 8-30 


RLT parameters in the third-party FAR message 


RLT parameter 


Facility Indicator 


Call Reference 


Operator Information 


Calling Party Number 


Called Party Number 


Generic Digits 


Comments 


This parameter defines the action that the FAR 
message requests at the bridging or remote 
switch. In this scenario, this parameter contains a 
Release Link for 3'4 Party Interaction Call value 
that the bridging switch uses. 


This parameter holds the switch’s call identification 
and point code values for a call. The bridging 
switch uses this information to bridge the correct 
two calls. 


Note: As each intermediate tandem switch 
passes this FAR message, it replaces this 
parameter’s call identification and point code 
values with values received in an ANM or ACM. 


This parameter provides information to the 
bridging switch, which places the information in 
the OPERNUMB, TRBLCODE, and ENTCODE 
fields in the OSR for the call. 


The switches, except bridging switches, copy the 
value of this parameter to the CALLING NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Calling Party Number 
parameter, the switch obtains billing information 
from the calls CDR and includes it in the call’s 
OSR. 


The remote switch copies the value of this 
parameter and adds it to the CALLED NUMBER 
field in the OSR for the call. If the FAR message 
does not include the Called Party Number 
parameter, the switch obtains billing information 
from the call’s CDR and includes it in the OSR. 


This parameter contains values for the following 
CDR fields merged from both call legs: 


e BILLNUM, value from second FAR 
UNIVACC, value from call setup 
PINDIGS, value from IAM 
ACCTCD, value from third FAR 
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17 Using the information in the FAR message, the remote switch identifies 
the associated call (the second call leg). By examining the point codes 
for the trunks of each leg of the call, it also determines whether both legs 
connect to the bridging switch. 


18 Because the point codes are the same, the remote switch retrieves the 
Call Reference information that it copied when it received the ACM 
from the bridging switch. The remote switch adds this Call Reference 
information to a FAR message and sends the message to the bridging 
switch. 


19 The bridging switch reads the message’s Facility Indicator and bridges 
the originating trunk of the first call leg to the terminating trunk of the 
second call leg. The bridging switch uses the information in the FAR 
message’s Call Reference parameter to identify the second leg. 


20 To acknowledge that it received and processed the FAR message, the 
bridging switch sends an FAA message to the remote switch, which 
passes it to the services platform. 


21 After bridging the call, the bridging switch formats two REL messages 
and sends them to the remote switch to release the call connections for 
both call legs. The REL messages include Normal Clearing Cause 
Indicator parameters. 


22 The remote switch sends two REL messages to the services platform and 
releases the call connections to the services platform and the 
corresponding trunks. It also sends two RLC messages back to the 
bridging switch to confirm the release of the first and second call legs. 
The RLC’s also include proper Cause Indicator parameters. 


Note: A switch can perform release link trunking immediately after 
sending a REL message, even before receiving an RLC response. 


23 The services platform also releases its connections and returns two 
RLC’s with proper Cause Indicator parameters to the remote switch to 
confirm the release of both call legs. 
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Figure 8-7 
Message flow for third-party interaction error scenario 
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Figure 8-7 
Message flow for third-party interaction error scenario (continued) 
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8-80 Common RLT billing scenarios 


Figure 8-7 
Message flow for third-party interaction error scenario (continued) 
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Figure 8-7 
Message flow for third-party interaction error scenario (continued) 
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8-82 Common RLT billing scenarios 


Figure 8-7 
Message flow for third-party interaction error scenario (continued) 
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9-1 


List of terms 


ACD 

automatic call distribution 
ACIF 

Authorization Code Identification Field 
ACM 

Address Complete Message 
AIN 

Advanced Intelligent Network 
AMA 

Automatic Message Accounting 
ANI 

automatic numbering identification 
ANM 

Answer Message 
ATD 

audio tone detector 
bridge 


connecting the originating or terminating trunk of one call to the terminating 
trunk of a second call 


bridging switch 
a switch that bridges calls and maintains the call connection 


CAIN 


Carrier Advanced Intelligent Network 


CDR 
call detail record 


Digital Switching Systems UCS DMS-250 SS7 RLT Feature Application Guide UCS12 


9-2 List of terms 


DAL 

direct-access line 
DN 

directory number 
DP 

detection point 
DTMF 

dual-tone multifrequency 
EAEO 

Equal Access End Office 
EANT 

equal access network trunk 
EDAL 

enhanced dedicated access line 
EOPS 

Enhanced Operator Position System 
ESP 

Enhanced Services Provider 
ETN 

Electronic Tandem Network 
FAA 

Facility Accept Message 
FAR 

Facility Request Message 
FCI 

Forward Call Indicator 
FGB 

feature group B 
FGC 

Feature Group C 
FGD 


Feature Group D 
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List of terms 9-3 


FRJ 
Facility Reject Message 
GD 
Generic Digits 
GAP 
Generic Address Parameter 
GNCT 
Generalized No Circuit 
IAM 
Initial Address Message 
IEC 
interexchange carrier 
IMT 
intermachine trunk 
ISDN 
Integrated Services Digital Network 
ISUP 
ISDN User Part 
JIP 
Jurisdiction Information Parameter 
LNP 
Local Number Portability 
LRN 
Local Routing Number 
MCCS 
Mechanized Calling Card Service 
NOA 


Nature of Address 


non-operator call 
call without a 0+ or 0- address 


NSF 


network-specific facilities 
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9-4 List of terms 


OA 


ONAL 


ONAT 


operator-assisted 


off-net access line 


off-net access trunks 


operator-initiated call 


call initiated by services platform to both call parties 


operator services call 


call with a 0+ or 0- address 


originating switch 


OSR 


PANI 


PIC 


POP 


PRI 


PTS 


REL 


Switch from which the first call leg starts 

operator services record 

pseudo-automatic numbering identification 

point in call 

Point of Presence or Originating Switch 

primary rate interface. 

An interface that carries nB+D channels over a digital DS-1 facility (23B+D 
in North America and 30B+D in Europe). PRI is used to link private 
networking facilities, such as private branch exchanges (PBX), local area 
networks (LAN), and host computers with a standardized architecture acting 


as the bridge between private switching equipment and the public network. 
Formerly known as primary rate access. 


per-trunk signaling 


Release 
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List of terms 9-5 


remote switch 
UCS DMS-250 switch that receives the incoming call and routes the call to 
an RLT platform. A remote switch can also be a bridging switch. It does not 
necessarily have EOPS hardware, but it connects to an ESP or other services 


platform. 
RLC 

Release Complete 
RLT 

release link trunk 
SCP 

Service Control Point 
SLI 

Supplementary Line Information 
SOC 

Software Optionality Control 
SS7 

Signaling System 7 
SSP 

Service Switching Point 
TDP 


Trigger Detection Point 


terminating switch 
switch to which the call returns: the call’s destination 


TRKGRP 
trunk group 
TRKSGRP 
trunk subgroup 
TOPS 
Traffic Operator Positioning System 
UAC 


universal access code 
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9-6 List of terms 


UCP 


Universal Carrier Protocol 


UCS 


Universal Carrier Services 
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Ordering information 


Use the following table for ordering Nortel Networks NTPs (Northern 
Telecom Publications) and Product Computing-Module Loads (PCLs): 


Type of product Source Phone Cost 
Technical documents Nortel Networks 1-877-662-5669, Yes 
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Documentation 
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PCL software Nortel Networks Consult your Yes 
Nortel Networks 
sales 
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When ordering publications on CD 
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